Re: GCC's statement expression extension

[Jeffrey A Law <law at cygnus dot com>]

  In message <Pine.SOL.4.21.0007220011570.29830-100000@orange.csi.cam.ac.uk>you
 write:
  > It seems GCC does not restrict gotos in and out of statement expressions,
  > even where they don't particularly make sense.  For example, the
  > nonsensical program
  > 
  > 	#include <stdio.h>
  > 	int main(void){ printf ("%d\n", ({a:; 0; })); goto a; }
  > 
  > dumps core for me on i686-pc-linux-gnu (after printing 0 many times).
Joys.  Note if we declare this valid behavior, then we should add this to the
"compile" part of the testsuite, else we should add it to the non-compile
part of the testsuite.

  > Is there any use for such jumps, or should this extension have a
  > constraint (in standards terminology) that a program shall not jump into a
  > statement expression from outside (with a mandatory error)?
I'm not really a language expert -- the way I tend to deal with this stuff
is ask myself _can_ the compiler deal with this situation in a sensible and
expected manner.  If it's simply impossible to deal with it in a sane manner,
then I recommend a constraint, else I recommend making the compiler generate
sane code.

  > Do jumps out of statement expressions work sensibly in GCC either (i.e.,
  > not crash, but with unspecified semantics relating to what of the
  > containing expression, except where subject to sequence point rules, has
  > been evaluated)?
Unknown.


  > Does GCC define the sequence point semantics of statement
  > expressions?  (For example, may evaluation of multiple statement
  > expressions within one containing expression be interleaved, cf the ruling
  > for DR#087 against the old C standard that function calls do not overlap?)
Unknown.


One of the long standing problems with GCC's extensions is they were not
well defined by the original authors -- lots of corner cases such as these
were never considered and thus there is nothing in the documentation about
the semantics of these cases.

I'm willing to go along with whatever makes the most sense from a language
design and implementation point of view.

jeff