From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Joseph S. Myers" To: Robert Dewar Cc: , , Subject: Re: forcing tail/sibling call optimization Date: Sun, 26 Nov 2000 16:21:00 -0000 Message-id: References: <20001126234619.A52E534D80@nile.gnat.com> X-SW-Source: 2000-11/msg01150.html On Sun, 26 Nov 2000, Robert Dewar wrote: > I think there is real merit in providing fairly formal specifications > for GNU C enhancements for three reasons. > > 1. The attempt to produce a FFS can often reveal difficulties that are > not apparent in a less formal approach. > > 2. If other C compilers want to copy the feature, which I assume we > welcome, then there is a clear guide. > > 3. If the ISO committee wants to copy the feature, which I assume > we welcome, then there is a clear guide. Indeed, it seems fairly impossible at present to work out what the specification of most GNU C extensions is supposed to be. A few months ago I noted problems with statement expressions. (See c/772 for conclusions from that long discussion.) Consider __attribute__, one of the most useful and widely used extensions. The syntax is nowhere specified. This was noted over three years ago ( http://bugs.debian.org/12253 - no documentation of where to put an attribute on a function definition). Attributes on labels seem not to be properly documented. The docs for -Wunused-label say you can put the "unused" attribute on a label, but the syntax is nowhere stated. Attributes do not work properly inside nested declarators - many of them should apply to a function type but instead apply only to a function declaration. The grammar has them as parts of declarations instead of parts of declarators, but function attributes clearly ought to be adding alternatives to the productions "direct-declarator: direct-declarator ( parameter-type-list )" and "direct-declarator: direct-declarator ( identifier-list_opt )" (from C99). Some attributes, if they can get parsed, do get attached to the function type (e.g. noreturn), but others don't; e.g. the format attributes work by adding to a list of format functions stored by DECL_NAME and DECL_ASSEMBLER_NAME (for C++ mangled names). The rules for composite types and compatible types in the presence of attributes are nowhere specified. Different attributes need to work differently here; those such as "const" and "format" that say more about the type need to work differently from those such as "packed" that change the type. Some of this is implemented (e.g. the internal use of "const" and "volatile" on function types is special cased to be different from that on object types), but it isn't documented. The grammar is also full of conflicts relating to attributes. There used to be a comment listing the conflicts that was removed because it was so out of date, but their presence perhaps indicates lack of careful design. Nowhere does the manual describe the conflicts and what the parsing rules are supposed to be (ideally the intended rules were checked against the parser resolution, but I strongly suspect that people have just increased the %expect value to quiet Bison rather than checking carefully in each case). I strongly agree that GCC extensions should have formal specifications (in the form of changes to the C99 or C++ grammar, as appropriate, plus specifications of constraints, semantics, and undefined behaviour). -- Joseph S. Myers jsm28@cam.ac.uk