lai@vedge.UUCP (David Lai) (12/07/88)
Why does something like:
/* taken straight out of X11/Intrinsic.h, from Xwindows from MIT */
typedef enum {
XtGeometryYes, /* Request accepted. */
XtGeometryNo, /* Request denied. */
XtGeometryAlmost, /* Request denied, but willing to take replyBox. */
XtGeometryDone, /* Request accepted and done. */
} XtGeometryResult;
/* note trailing comma after XtGeometryDone */
elicit no complaints from any of the C compilers I use? I have a couple of
theories:
1) This is an archaic remnant from bygone days when enums syntax
allowed trailing commas
2) This is a bug in the original C compiler, from which all other C
compilers were ported from. I suspect this because of the
vast number of systems that X has been ported to using the
above file.
3) The books are wrong, the syntax should really read:
enum_type_def: enum opt_enum_tag { enum_def_list }
| enum opt_enum_tag { enum_def_list , }
4) The C compiler writers were forced to stray from the specification
because of files like the above.
5) Perhaps I'm misinformed, and a trailing comma has some sort of
special hidden meaning...
Is this a bug or feature? Should ANSI compilers allow this? I only caught
this because I'm designing a C parser directly from the specifications.
I hope somebody in the X consortium sees this (and corrects it for the next
release).
The C standard (and every book on C I've seen, including those from
AT&T) says the syntax of an enum declaration is:
enum_type_def: enum opt_enum_tag { enum_def_list }
enum_def_list: enum_const_def
| enum_def_list , enum_const_def
enum_const_def: enum_constant
| enum_constant = expression
--
"What is a DJ if he can't scratch?" - Uncle Jamms Army
The views expressed are those of the author, and not of Visual Edge, nor Usenet.
David Lai (vedge!lai@larry.mcrcim.mcgill.edu || ...watmath!onfcanim!vedge!lai)gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/07/88)
In article <2174@vedge.UUCP> lai@vedge.UUCP (David Lai) writes: >Is this a bug or feature? An unofficial feature. >Should ANSI compilers allow this? Definitely not! Trailing comma in an initializer list is allowed, though.
leendert@cs.vu.nl (Leendert van Doorn) (12/08/88)
In article <2174@vedge.UUCP> lai@vedge.UUC writes: >Why does something like: > >/* taken straight out of X11/Intrinsic.h, from Xwindows from MIT */ >typedef enum { > XtGeometryYes, /* Request accepted. */ > XtGeometryNo, /* Request denied. */ > XtGeometryAlmost, /* Request denied, but willing to take replyBox. */ > XtGeometryDone, /* Request accepted and done. */ >} XtGeometryResult; > /* note trailing comma after XtGeometryDone */ > >elicit no complaints from any of the C compilers I use? You're probably using PCC which has the following grammar for enums: enum_dcl: enum_head '{' moe_list optcomma '}' | ENUM NAME ; enum_head: ENUM |ENUM NAME ; moe_list: moe | moe_list CM moe ; moe : NAME | NAME '=' con_expr ; optcomma: /* epsilon */ | ',' ; This feature is only useful when automaticly generating enum tags (e.g. by macros; in this case it's very hard to remove the last trailing comma). Any further usage is unknown to me. I think that the designers (was this an invention of Steve Johnson?) wanted to conform to the initialization syntax. >Is this a bug or feature? An undocumented feature. >Should ANSI compilers allow this? No, they shouldn't. However in the ANSI C compiler I wrote, the trailing comma is accepted but flagged by a warning message. This makes it possible to compile things like gcc and X11. -- Leendert P. van Doorn <leendert@cs.vu.nl> Vrije Universiteit / Dept. of Maths. & Comp. Sc. De Boelelaan 1081 1081 HV Amsterdam / The Netherlands tel. +31 20 548 5302
gregg@ihlpb.ATT.COM (Wonderly) (12/08/88)
From article <9095@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): > In article <2174@vedge.UUCP> lai@vedge.UUCP (David Lai) writes: >>Is this a bug or feature? > > An unofficial feature. > >>Should ANSI compilers allow this? > > Definitely not! Trailing comma in an initializer list is allowed, though. At first sight it appears to not be necessary, however it does prove to be a benefit in some software modification control environments that I know about. If the initial definition of an enum is say typedef enum FOO { VALUE1, VALUE2, } FOO_CONST; and a modification changed it to typedef enum FOO { VALUE1, VALUE2, VALUE3 } FOO_CONST; and finally another modification changed it to typedef enum FOO { VALUE1, VALUE2, VALUE3, VALUE4, } FOO_CONST; The modification control system that I know about would say that the third modification is 'dependent' on the second in a physical way because a line of code was changed. Now obviously, the comma could be placed on the line with VALUE4, but that is not the typical nor desireable coding style. By leaving the trailing comma there, future modifications are easily made without additional changes and dependencies needed. -- It isn't the DREAM that NASA's missing... DOMAIN: gregg@ihlpb.att.com It's a direction! UUCP: att!ihlpb!gregg
henry@utzoo.uucp (Henry Spencer) (12/13/88)
In article <2174@vedge.UUCP> lai@vedge.UUCP (David Lai) writes: >typedef enum { ... > XtGeometryDone, /* Request accepted and done. */ >} XtGeometryResult; > /* note trailing comma after XtGeometryDone */ > >elicit no complaints from any of the C compilers I use? Probably all the C compilers you are using are PCC-derived or attempting to be PCC-compatible. In several contexts, the AT&T compilers are willing to overlook a missing trailing delimiter or accept an extra trailing separator. The only place where this looseness actually made it into the *documentation*, however, was the optional trailing comma in an initializer list. X3J11 declined to legitimize it elsewhere, so a strictly conforming program cannot rely on it (October draft section 1.7), and a conforming implementation must complain about use of it (2.1.1.3). Note, however, that a conforming implementation is not required to refuse to compile it. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu