On 2/2/2017 1:21 AM, Claude wrote:
> On Wednesday, 1 February 2017 at 21:16:30 UTC, Walter Bright wrote:
>> 6. Valgrind isn't available on all platforms, like Windows, embedded systems,
>> phones (?), etc.
>
> You can use valgrind on embedded systems as long as they run a GNU/Linux OS.
> I've used valgrind successfully many times on ARM architecture.
> But I don't know if it works with Android, and I doubt it works on baremetal
> indeed.

I seem to recall Valgrind wasn't on OSX, either, at one point. Maybe that has since been corrected.

On Thursday, 2 February 2017 at 09:28:15 UTC, Walter Bright wrote:
> On 2/2/2017 1:21 AM, Claude wrote:
>> On Wednesday, 1 February 2017 at 21:16:30 UTC, Walter Bright wrote:
>>> 6. Valgrind isn't available on all platforms, like Windows, embedded systems,
>>> phones (?), etc.
>>
>> You can use valgrind on embedded systems as long as they run a GNU/Linux OS.
>> I've used valgrind successfully many times on ARM architecture.
>> But I don't know if it works with Android, and I doubt it works on baremetal
>> indeed.
>
> I seem to recall Valgrind wasn't on OSX, either, at one point. Maybe that has since been corrected.

Also, unless you're testing possible bugs in compiler backends or the C standard library, it mostly doesn't matter. Compile on regular x86/Linux and run valgrind/asan there.

Have I run into weird bugs that only occurred on one platform? Yes. Were they _really_ rare? You betcha. *

Atila

* At one point I had a bug where casting from double to uint64_t failed for values over the integer maximum for 32-bits... (turns out that platform had no FPU and it was a bug in its libc)

On Thursday, 2 February 2017 at 09:28:15 UTC, Walter Bright wrote:
> I seem to recall Valgrind wasn't on OSX, either, at one point. Maybe that has since been corrected.

It nominally works on 10.10, if I recall correctly, but not to the same standard as on Linux.

For C/C++, a combination of the various Clang sanitizers works faster and catches more bugs, though.

 — David

On Thu, 02 Feb 2017 14:19:02 +0000, Atila Neves wrote:
> Also, unless you're testing possible bugs in compiler backends or the C standard library, it mostly doesn't matter. Compile on regular x86/Linux and run valgrind/asan there.

Assuming you're writing cross-platform code. How common is that? I write Java for a living, and some of my code only works on Linux. (It does at least fail gracefully on OSX, which my coworkers use.)

On Wednesday, 1 February 2017 at 23:49:29 UTC, H. S. Teoh wrote:
> We would love to change the defaults, but unfortunately that boat has already sailed a long time ago.

What if d had a -safe-defaults switch? It should be ok, since safe is stricter than unsafe right?

This way old/existing code would compile fine by default, but if you want to use that code/lib with safe-defaults you either have to do trusted wrappers or modify it to be safe.

All new code with safe-defaults would compile fine in safe mode and unsafe mode.

To me it's similar approach to 'warnings-all' and 'warnings-as-errors'.

---

I myself don't really care for @safe, it's complex and seems to have big practical hole with @trusted. Kind of like 'refs can't be null in c++' (as some people claim/argue) and then someone passes nullptr into function ref arg. Completely unreliable, even though refs  usually work ok 99% of the time (by conventions and effort).

I've already thrown const, immutable, inout mostly in to trash (string literals etc. are exception) after few tries. They make the code more complex and harder to modify especially when you have bigger system. Often you realize that your system/module isn't truly 100% const in the last insignificant leaf function, and that triggers large  cascading modifications and rewrites, just to get the code work. Also I can't really remember when I accidentally modified data that I shouldn't have (i.e. violate const protection). But I often modify correct data incorrectly. I believe most programmers first figure out what they need to do before doing it instead of just writing randomly into some array/pointer that looked handy :)

I prefer flexible (fun), fast and debuggable (debugger/printing friendly) code. It seems that neither @safe or const are part of it. (I'm not writing life and death safety critical code anyway).

On 2/2/2017 6:19 AM, Atila Neves wrote:
> Also, unless you're testing possible bugs in compiler backends or the C standard
> library, it mostly doesn't matter. Compile on regular x86/Linux and run
> valgrind/asan there.

I've often been able to flush out difficult bugs by compiling on another platform.

Back in the bad old DOS days, I quickly learned to develop the programs on a protected mode operating system, then port to 16 bit real mode DOS as the last step. :-)


> Have I run into weird bugs that only occurred on one platform? Yes. Were they
> _really_ rare? You betcha. *

Memory corruption bugs show themselves differently on different platforms, and one of them likely will make it easier to find the bug.

On 2/2/2017 8:44 AM, Chris Wright wrote:
> Assuming you're writing cross-platform code. How common is that?

Exactly. That's why Valgrind is not a substitute for a language that offers memory safety features.

On 2/2/2017 12:37 PM, Random D user wrote:
> I prefer flexible (fun), fast and debuggable (debugger/printing friendly) code.
> It seems that neither @safe or const are part of it. (I'm not writing life and
> death safety critical code anyway).

One nice feature of D is you don't have to use const, @safe, etc., if you don't want to. But for high stakes software, there's no substitute.

On Thursday, 2 February 2017 at 16:44:26 UTC, Chris Wright wrote:
> On Thu, 02 Feb 2017 14:19:02 +0000, Atila Neves wrote:
>> Also, unless you're testing possible bugs in compiler backends or the C standard library, it mostly doesn't matter. Compile on regular x86/Linux and run valgrind/asan there.
>
> Assuming you're writing cross-platform code. How common is that? I write Java for a living, and some of my code only works on Linux. (It does at least fail gracefully on OSX, which my coworkers use.)

Ah, Java: write once, debug everywhere. :P

I almost always write cross-platform code. In C or C++, valgrind/asan will catch nearly all memory corruption problems on plain Linux. It's only weird corner cases that escape.

Which isn't to say you won't have Windows-only bugs, say. What I'm saying is if you read past the end of an allocated buffer you don't _need_ to test on all platforms. That'll be caught. i.e. the lack of valgrid on Windows or an embedded platform isn't a big deal.

Atila

On Thursday, 2 February 2017 at 20:50:58 UTC, Walter Bright wrote:
> On 2/2/2017 6:19 AM, Atila Neves wrote:
>> Also, unless you're testing possible bugs in compiler backends or the C standard
>> library, it mostly doesn't matter. Compile on regular x86/Linux and run
>> valgrind/asan there.
>
> I've often been able to flush out difficult bugs by compiling on another platform.
>
> Back in the bad old DOS days, I quickly learned to develop the programs on a protected mode operating system, then port to 16 bit real mode DOS as the last step. :-)

That I can see the value in. But (fortunately) those days are long gone.

>
>
>> Have I run into weird bugs that only occurred on one platform? Yes. Were they
>> _really_ rare? You betcha. *
>
> Memory corruption bugs show themselves differently on different platforms, and one of them likely will make it easier to find the bug.

Right, but we're talking about finding memory corruption bugs _before_ they manifest themselves. As I mentioned in my other reply, if you have memory corruption bugs in common cross-platform code, valgrind and asan will (nearly always) catch them. You don't need to wait for weird effects that are hard to trace back. Run on Linux with both valgrind and asan and you'll be fine 99.9%*  of the time.

Atila

* stats totally made up