Re: bug(s) in 2.5.19 skel.c

[Hans-Bernhard Broeker]

On Tue, 17 Sep 2002, Bruce Lilly wrote:

> 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?!?

It does, but access to it from this desk here is quite a bit too slow
--- and now that I'm looking for it, it appears they don't have a copy of
X3.159-1989 or ISO 9899:1990 at hand, either.

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

I don't remember having said anything like that, sorry.  Quotation,
please?

An integer-type variables is an _interpretation_ of a collection of bytes.  
All this discussion is about the widely unknown pitfalls in that
interpretation process.

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

Which, of course, raises the age-old question: in case of conflict, what
is more sane and/or important: taking care of already broken platforms, or
avoiding to break the un-broken ones?

> The assignment of const struct foo default_foo to (not const) struct
> foo *x will almost certainly generate a diagnostic about qualifier
> mismatch (const).

Such a warning should be considered insane and ignored, IMHO.  But yes, I
know it happens. If the compiler author who put in that warning thinks I
shouldn't assign a const value to a non-const variable, then what on earth
does he think the "const" attribute is supposed to be useful for?

The issue is, what do you care for more: avoiding silly warnings from
silly compilers, or avoiding known-unportable code that might just solidly
break tomorrow, as you try a new compiler option or hardware platform you
never used before?

> Bear in mind that the definition of struct foo, the definition of
> default_foo, the initialization of default_foo,

The definition and initialization of a const cannot be in different
places. The declaration may be elsewhere, granted, but not the definition.

> the malloc, and the structure assignment (incidentally, structure
> assignment is not guaranteed to work on old compilers)

Use memcpy(), then.  

And if you really worry about the coherence that much, create a macro or
function that combines the malloc() and initialization, as in

#define NEW_STRUCT(struct_type, initial_values)  (/* ... */)

        struct foo *x = NEW_STRUCT(foo, default_foo);

Or even apply some preprocessor concatenation to link the names of the
struct and the default initializer, and save one argument.

Or run your own preprocessor that takes more abstract, conditionalized
struct definitions and spits out all the relevant source snippets properly
synchronized with each other, like GCC does it in all those
"gen{something}" helper programs.

-- 
Hans-Bernhard Broeker (address@hidden)
Even if all the snow were burnt, ashes would remain.