emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c


From: Óscar Fuentes
Subject: Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c
Date: Mon, 26 Aug 2019 21:15:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Óscar Fuentes <address@hidden>
>> Date: Mon, 26 Aug 2019 20:20:23 +0200
>> 
>> Valgrind knows nothing about UNINIT as it works with machine code, not
>> with source code. But AFAIK that macro is conditionally defined to "=0"
>> (for silencing bogus gcc warnings) or to nothing (for leaving the
>> variable uninitalized at the declaration point). The later allows
>> Valgrind to do a proper check.
>> 
>> Simply changing
>> 
>> int x;
>> 
>> to
>> 
>> int x = 0;
>> 
>> just for silencing the gcc warning can hide a bug that Valgrind would
>> detect otherwise.
>
> This is backwards: it would mean we should use UNINIT all over the
> place just to be sure we will be able to spot some imaginary bugs by
> flipping a compiler switch.

UNINIT should only be used to avoid bogus warnings, *actual* bogus
warnings, not potential ones.

> The initialization in this case was added because GCC flagged a
> potential use-before-define.  After that, there's no more bug for
> Valgrind to find, so I see no reason to leave UNINIT around.

Let's suppose that the warning was correct and the hacker was wrong when
judged it bogus. Adding the initialization silences the warning *and*
Valgrind, while the UNINIT trick would cause Valgrind to complain (when
Valgrind examines an Emacs executable built with the options that cause
UNINIT to be empty.)

Or suppose that the warning is indeed bogus now. By adding the
initialization you are precluding Valgrind to find a bug if some future
code change introduces it.

> I could understand using UNINIT (or something similar) when the
> developer has no idea what not initializing could cause.  But this is
> not that case.

One of the most important things of the mental model of a C/C++ hacker
is the declare->initialize->use->dispose sequence of any storage. If the
developer is unsure about where to initialize a variable, he must stop
and think. The declaration should do the initialization only when it is
the right thing, that means that the variable must have that value from
that point. A variable shouldn't be assigned before the point where the
information it is supposed to store is available.

(Sorry if that sounds as if I were giving a lesson, that's not my
intention at all. I'm sure that you know what I explained by heart, but
it seems to me that you are not fully aware of the fact that some tools
do provide reliable detection of certain conditions that the compilers
tried half-assedly to detect for ages only to annoy experienced hackers
and force them to use workarounds that now are counterproductive.)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]