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: Paul Eggert
Subject: Re: [Emacs-diffs] master 6cd5678: Clarify compiler-pacifier in frame.c
Date: Tue, 27 Aug 2019 02:28:42 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

Eli Zaretskii wrote:
How do you know whether (geometry & XValue) is nonzero in each
relevant use case?
By reading the source code. Although it's simple enough, here's a very detailed 
analysis to make sure we're on the same page.
In Fx_parse_geometry, every use of the local variable x must be preceded by an 
initialization of x, because every use is guarded by (geometry & XValue) and 
this test succeeds only when x is initialized. The initialization is done not 
directly by Fx_parse_geometry, but by a function that Fx_parse_geometry calls.
This sort of thing is common. E.g., image_create_bitmap_from_file does this:

   490    unsigned int width, height;
   ...
   517    result = XReadBitmapFile (FRAME_X_DISPLAY (f), FRAME_X_DRAWABLE (f),
518 filename, &width, &height, &bitmap, &xhot, &yhot);
   519    if (result != BitmapSuccess)
   520      return -1;
   ...
   528    dpyinfo->bitmaps[id - 1].height = height;
   529    dpyinfo->bitmaps[id - 1].width = width;

Here too there is no path through the code where 'width' and 'height' can be used before being set, because every use of 'width' and 'height' is guarded by (result == BitmapSuccess) and this test succeeds only when 'width' and 'height' are initialized. Hence image_create_bitmap_from_file need not initialize 'width' and 'height' in line 490, since XReadBitmapFile initializes them when it returns BitmapSuccess. Also, 'width' and 'height' should not be marked with UNINIT here since GCC does not warn here. GCC's lack of warning here does not mean that GCC knows that width and height are initialized: all it means is that GCC's heuristics for warnings do not elicit a warning here.
There are two reasons that omitting UNINIT causes GCC to warn about 
Fx_parse_geometry but not image_create_bitmap_from_file. First, under MS-Windows 
GCC has access to the source code of the initialization function XParseGeometry 
that Fx_parse_geometry calls, whereas under X Windows GCC lacks access to the 
source code of the initialization function XReadBitmapFile that 
image_create_bitmap_from_file calls (I am assuming typical builds without fancy 
link-time optimization). Second, GCC does not fully grok the source code of 
MS-Windows XParseGeometry; GCC gets lost and thinks that there's a path through 
Fx_parse_geometry + XParseGeometry that will use Fx_parse_geometry's x without 
initializing it, even though there is no such path.
And how should GCC know that?
GCC could use the same sort of reasoning I used. And perhaps some future version 
of GCC will do that. But in the meantime GCC gives a false alarm, so UNINIT is 
warranted here.
UNINIT is precisely for this sort of situation: the programmer knows that a 
variable need not be initialized, but GCC falsely warns about the lack of 
initialization.


reply via email to

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