On Mon, Feb 18, 2013 at 9:43 AM, Jonathan Wakely <jwakely....@gmail.com> wrote:
> On 18 February 2013 13:28, Jeffrey Walton wrote:
>> The reason I went looking for the flag is someone asked about a crash
>> on the OpenSSL mailing list. I knew it was due to an uninitialized
>> field (but they did not realize the value was not initialized). I
>> wanted to suggest a quick way to find what was not initialized.
>
> Valgrind.
That requires an additional package, and some developers don't use it.
>> How much code do you think would break because folks depend on getting
>> a 0 due to good graces or side effects (for example, the memory
>> manager returning a zeroized page)?
>
> It should break no valid programs. The invalid programs that break
> would benefit from an easily reproducable failure.
Right.
>> What if the ".BSS" section was
>> initialized to 0xFF rather than a page full of NULLs?
>
> That could break millions of perfectly valid programs, for no obvious benefit.
Its hypothetical, and could be a bit humorous. Why are developers
writing programs that rely upon undocumented features?
As crazy as it sound, it probably portable though. Are there any OS
link/loaders which use a memory manager that does not serve zeroized
pages (at least on the first run when drawing from a fresh pool)?
It not just userland. I've looked at lots of kernel code that relies
on the same good graces and luck. I'd love to see the effects of the
memory manager returning a page filed with HASH(counter).
>> When building for tools such as Valgrind, don't specify the flag ;)
>
> You don't build for valgrind, it runs normal, uninstrumented binaries.
> That's one of its main advantages.
Yes, agreed. The switch would *not* be specified for production code
('release' builds). But I'm talking about development ('debug'
builds).
Jeff
