Re: return'ing a struct and trap representations

[Ralf Wildenhues]

Hello Bruno,

* Bruno Haible wrote on Fri, Sep 22, 2006 at 03:34:14PM CEST:
> 
> > 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.

Certainly.

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

Yes.  But the fact that it helped me find several actual issues in
gnulib, and the fact that the signal to noise ratio was quite high,
makes these settings a very useful tool.

> 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).

I don't understand this explanation.  If, for integer and pointer types,
there are "trap representations", but copying the struct that contains
them is not a problem, then the copying must be akin to accessing the
memory as a chararacter array; so why would that not hold for doubles?
Note the members I was mentioning are not character arrays, so the above
does not hold for them.

But meanwhile I found out another reason why there is no actual problem
here: all potentially uninitialized variables are size_t ones, thus
unsigned integer types; these do not have trap representations.

> > ok to apply?
> 
> No. The patch adds useless memory stores which slow down the code.

Of course.  Do you think it would be useful to add debug code to
initialize them (guarded by some preprocessor define that evaluates to 0
by default)?

Cheers,
Ralf