Re: [Valgrind-users] Uninitialized values with fortran

[John R. <jr...@bi...>]

> This example also shows that the memcheck error descriptions should
> be taken with a grain of salt i.e. the error may be occurring elsewhere, and
> not where the error description is suggesting.  Is this the nature of the beast,
> or can memcheck be more accurate in locating the errors?

Memcheck has decided not to complain unless the uninit affects control flow,
file output, or an index expression for array access.  This is motivated
by an attempt to reduce "false positive" complaints: those that "do not affect
the output", and thus "the user does not care about them."  If there are
too many false positive complaints, then users quickly ignore *ALL* complaints
(that is, the user discards memcheck as not useful.)
Also, alignment and padding in 'struct's often result in uninit "holes"
that are copied indiscriminately, and often the end programmer
cannot do anything about these because those holes were specified as part of
some inner ABI.  Also, gcc tends to "overfetch" scalar char and short operands
(fetches 32 bits regardless of actual length being 16 or 8),
and the overage often is uninit.

*UNFORTUNATELY*, memcheck's policy of complaining "as late as possible"
means that serious users often experience a really tough debugging chore
because the source of the error happens very much earlier than the complaint.
It would be much nicer if memcheck had the *OPTION* to complain "as soon
as possible": namely, as soon as any uninit bits are fetched from memory.
The serious user will either fix the holes in alignment and padding,
or write suppressions, or otherwise ignore what is not interesting
at the moment, in order to eradicate the *source* of the uninit-of-the-moment.
But the implementers of memcheck are not yet convinced.