[Top][All Lists]

[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]