On 8/26/22 11:30, Walter Bright wrote:

> It is. The first use case I mentioned was initializing data returned
> from malloc to DEADBEEF. malloc returns uninitialized data, and I wanted
> to make sure it wasn't data that just happened to be 0 and "work",
> because therein lies heisenbugs and madness.

Microsoft's C++ compiler used to do and probably still does that. Newly allocated memory and freed memory are initialized with specific patterns. (Optionally, I think with a compiler switch.)

Ali

On Friday, 26 August 2022 at 18:53:33 UTC, Ali Çehreli wrote:
>
> Microsoft's C++ compiler used to do and probably still does that. Newly allocated memory and freed memory are initialized with specific patterns. (Optionally, I think with a compiler switch.)
>
> Ali

I don't think it would do that in release mode. However, in debug there are several things going on with the VC C++ compiler. I haven't checked if it patterns malloc/free memory but it certainly patterns the stack memory and puts variables apart with guard patterns in between. Upon function/frame exit it checks all this. This is dog slow but very useful and I have found many bugs thanks to this. This of course will be unacceptable in a release build. Also initialize malloc/free with pattern would be undesirable in a release build.

On Friday, 26 August 2022 at 20:37:40 UTC, IGotD- wrote:
> On Friday, 26 August 2022 at 18:53:33 UTC, Ali Çehreli wrote:
>>
>> Microsoft's C++ compiler used to do and probably still does that. Newly allocated memory and freed memory are initialized with specific patterns. (Optionally, I think with a compiler switch.)
>>
>> Ali
>
> I don't think it would do that in release mode. However, in debug there are several things going on with the VC C++ compiler. I haven't checked if it patterns malloc/free memory but it certainly patterns the stack memory and puts variables apart with guard patterns in between. Upon function/frame exit it checks all this. This is dog slow but very useful and I have found many bugs thanks to this. This of course will be unacceptable in a release build. Also initialize malloc/free with pattern would be undesirable in a release build.

Except Windows is actually compiled in release mode with local variables being initialized.

https://msrc-blog.microsoft.com/2020/05/13/solving-uninitialized-stack-memory-on-windows/

And Android as well,

https://source.android.com/docs/security/memory-safety/zero-initialized-memory?hl=en

On 8/25/2022 11:05 AM, Bastiaan Veelo wrote:
> Compile with LDC and options `--ffast-math -O`.


https://stackoverflow.com/questions/7420665/what-does-gccs-ffast-math-actually-do

I'd stay away from fast-math. If you want to use it, however, you're on your own as D assumes IEEE math.

On 25.08.22 18:56, Walter Bright wrote:
> On 8/25/2022 9:16 AM, IGotD- wrote:
>> Which is strange because HW wise it is trivial to check if the result is NaN. To check that NaN is not based on input is of course more complicated. Then again an x86 complicated in an unhealthy way.
>>
>> This kind of makes another motivation to let floats default to zero, if this is correct.
> 
> 
> There's nothing to be afraid of in getting a NaN in the output. One should be glad, because then one *knows* there's a bug.
> 
> This thread reminds me of the threads about assert, and the contention that the program should continue after a failed assert.
> ...

Clearly you should throw away your computer after a failed assert.

> 1. It is not better to pretend a program is working when it is not.
> 
> 2. It is not better for a language to guess at what the programmer must have meant, even if the guess is correct 99% of the time.
> 
> 3. It is not better to never check the output of the program for correctness.
> 
> D is a tool for helping the programmer create correct, robust, and bug-free programs.

Which is why asserts can introduce new _undefined behavior_?

On 26.08.22 20:30, Walter Bright wrote:
> 
> 
> I am not making this up for the n.g. I have a *lot* of experience with it. I'm pointing out techniques that work. DEADBEEF turns a heisenbug into a reproducible bug. If it is reproducible, it is findable and fixable.
> 

D's assert semantics may turn a reproducible bug into a heisenbug.

On Sunday, 28 August 2022 at 18:31:37 UTC, Walter Bright wrote:
> On 8/25/2022 11:05 AM, Bastiaan Veelo wrote:
>> Compile with LDC and options `--ffast-math -O`.
>
>
> https://stackoverflow.com/questions/7420665/what-does-gccs-ffast-math-actually-do
>
> I'd stay away from fast-math. If you want to use it, however, you're on your own as D assumes IEEE math.

+1

"fast math" it also different from compiler to compiler, and sometimes makes things slower!

Do you even need it for performance? Not sure, as just working on your vectorization, be it automatic or explicit, will leads to way better results. At least, that's my experience using the LLVM backend.