Re: about a stack fill option (as for malloc-fill and free-fill)

Paul Floyd <[email protected]> Thu, 30 Mar 2023 09:15:30 +0200
Newsgroups gmane.comp.debugging.valgrind
Message-ID <[email protected]>

On 29-03-23 04:41, John Reiser wrote:
>>>      Could it be possible to add an option like --heap-up-fill 
>>> --heap-down-fill (like for stack with malloc), that fills heap memory 
>>> with a specified values (when entering a function and leave a function)?
> 
>> tl;dr 2
>>
>> See
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html
> 
> The value zero is the worst possible value to use for such initialization,
> from the viewpoint of quickly producing better software by discovering
> and identifying bugs sooner.  Using the value zero tends to hide many bugs.
> 
> A much better value is 0x8181...81.  This value is non-zero, odd, negative
> as a signed integer, a very unlikely floating-point value, very often
> not a valid pointer value, and instantly recognizable in any dump of 
> memory.
> It was used to great success as the "core constant" (the value of 
> uninitialized
> RAM) by the Michigan Terminal System for IBM 360/67 and successors,
> from the early 1970s (50 years ago!) until the demise of MTS around 2000.

Hi John

The value 0 isn't all bad.

I quite often write code that uses enums that start with KIND_INVALID so 
then I can write asserts like assert(kind != KIND_INVALID);

0 is also the NULL pointer so if your code defends against NULL it will 
at least not crash. I agree with you about early detection of errors - 
in a previous job we had loads of "pass the parcel" code that just 
ignored errors and returned from functions without reporting an error. 
It was a nightmare to debug,

The value used with 'pattern' is 0xAA which isn't too bad either - 
fairly well known as being a test pattern.

A+
Paul


_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users