Re: bug(s) in 2.5.19 skel.c

[Bruce Lilly]

Hans-Bernhard Broeker wrote:
> On Tue, 17 Sep 2002, Bruce Lilly wrote:

> I'm aware of that.  Unfortunately, getting ahold of the real standard is
> hideously expensive around here.  

rwth-aachen.de doesn't have a library?!?

> > memset specifically deals with a collection of bytes, setting each
> > member of that collection to the value of its second argument as
> > an unsigned char.
>
>
> Exactly.  And it specifically does *not* deal with any other type.
> Since an integer is not just a collection of bytes

In your last message, you said that it was legal and valid to
treat it as a collection of bytes.

> The same can be achieved by:
>
>         const struct foo default_foo = {0 };
>         struct foo *x = malloc(sizeof(*x));
>         *x = default_foo;
>
> Here the compiler does the conversion from a zero to a pointer, and thus
> will do the right thing.  And the initializer for the default struct will
> automatically extend to initialized whatever elements the struct happens
> to have in a given compilation of the code, too.

If struct foo has had elements added, your
default_foo might not be initialized completely (at
least in some implementations), and it is likely to
lead to compiler warnings even in those cases where
the initialization is complete. The assignment of
const struct foo default_foo to (not const) struct foo
*x will almost certainly generate a diagnostic about
qualifier mismatch (const).  And if initializers
are added to default_foo to correspond to additional
elements in struct foo's definitions, and subsequent
changes are made that then remove some elements from
struct foo, default_foo will have too many initializers.
Bear in mind that the definition of struct foo, the
definition of default_foo, the initialization of
default_foo, the malloc, and the structure assignment
(incidentally, structure assignment is not guaranteed
to work on old compilers) might all be in different
files, and that's a maintenance nightmare. At best,
you have substituted known, documented non-portable
code for (theoretically non-portable) code which is
known to work reliably, there will be annoying compiler
diagnostics even if the code works, and you have added
a maintenance problem as well.  The non-portable nature
of your suggested code (particularly w.r.t. old compilers)
would be a problem where flex-generated scanners are
used to bootstrap gcc on old systems.