Re: return'ing a struct and trap representations

[Bruno Haible]

Hello Ralf,

> GCC 4.0.3 and newer (with `-Wall -Werror -fno-builtin' on a GNU/Linux
> x86_64 system) errors out at some of the list implementation
> "constructor" functions:
> | gl_array_list.c: In function ‘gl_array_iterator’:
> | gl_array_list.c:398: warning: ‘result.j’ is used uninitialized in this 
> function
> | gl_array_list.c:398: warning: ‘result.i’ is used uninitialized in this 
> function

It is ok for gcc to warn about this with -Wall, since uninitialised values
in structs can be bugs, like uninitialised variables on the stack.

But the combination -Wall -Werror is a masochistic one.

> Now I have a question here: the structures in question are created on
> the stack, and then passed to the calling function with `return'.  Does
> the return expression count as accessing the value of the automatic
> object?  Because if it does, then I read C99 6.2.6.1(5) and footnote 41
> such that the values have to be initialized, if we want to avoid
> undefined behavior: the variables could otherwise contain trap
> representations.

Right. If the struct fields were floats or doubles, there would be a
bug in the code, because if the bit pattern found in the uninitialized
memory locations correspond to a "signalling NaN", the code for copying
the struct could abort().

However, for integer and pointer types there are "trap representations".
We use uninitialized memory locations constantly, in all kinds of
structs such as

  struct utsname
  {
    char sysname[64];
    char nodename[64];
    ...
  }

Typically each part of the struct is initialized up to the '\0' and
not further. But the struct is copied as a unit. These things occur
very frequently and are not a problem, because there are no trap
representations for 'char'. And gcc does not warn about them (as long
as you don't pass the array to an inline function which accesses the
characters one by one).

> ok to apply?

No. The patch adds useless memory stores which slow down the code.

Bruno