🚀 go-pugleaf

Ben Wing (wing@netcom.com) wrote:
: This question arises out of a discussion I had with Chris Torek
: <torek@elf.bsdi.com>.  Basically, after discovering about the 12th
: case in which GCC apparently generated incorrect code (in cases
: where other compilers certainly did not do this), I posted a
: message to gnu.gcc.bugs about how GCC sucked, etc. and here were
: all the bugs, etc.  One of these bugs occurred in the statement

:      keymap = make_number (string_char (XSYMBOL (keysym)->name, 0));
       ^^^^^^
-snip-
: make_number() is actually a macro that uses GCC's "construct a union"
: language extension, like this:
-snip-
: Anyway ...  the statement as written triggers the assertion failure
: even though keysym is of the correct type before the statement.
: What appears to be happening is that GCC is modifying the value
: of keymap *before* completely evaluating the right-hand-side; in
: other words, the expression is being converted to

: keysym.gu.markbit = 0;
: keysym.gu.type = Lisp_Int; /* Lisp_Int is an enum constant */
: keysym.val = (unsigned int) string_char (XSYMBOL (keysym)->name, 0);
  ^^^^^^

: I claim that this behavior is completely bogus and is a bug in GCC.
: Chris claims that the ANSI C standard does not actually forbid this
: bogosity from happening, or at least is not explicit about this.

0: Any compiler that converts an assigment to keymap to an assignment
        to keysym is certainly weird.
1: If you use GCC extensions then the ANSI C rules can't protect you.
2: ANSI C does allow structure assigment to take place field by field.
   I don't think there is a sequence point in your expression.
   So probably the behaviour would be correct if ANSI C allowed operations
        that constructed structures. However it only allows structure 
        assignment in circumstances where the structure being assigned is
        already complete.
   If operations to construct structures were added to the standard in 
        the future, then a sequence point of some sort needs to be added
        to the assignment to stop this happening.

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom