comma at end of enumerator-list
Tim Roper
(a) a trailing comma at the end of an enumerator-list is not allowed,
as in:
enum bletch {
foo,
bar,
};
(b) enum tag namespace is the same as that for struct and union tags
I am trying to figure out why I previously thought otherwise. Of course enums
were not part of K&R1. I think it may have been the unix v7 C reference
manual that my understanding of enums was based on but I do not have access to
a copy now. (It also covered struct arguments and returns.)
Can anyone remind me? Does anyone know if (a) was considered an issue by X3J11
and whether it is mentioned somewhere in the Rationale?
Please note that I am not crusading but simply confused about why I
thought (a) was common usage and (b) was not true.
-Tim.
Henry Spencer
> (a) a trailing comma at the end of an enumerator-list is not allowed,
>and whether it is mentioned somewhere in the Rationale?
It does not appear to be mentioned. If memory (of a secondhand report)
serves, the issue was raised but lack of implementation experience weighed
against it, as did dislike for unnecessary complexity in a feature that was
considered only barely worth including in the standard at all.
(You wouldn't know it from the way some people rant about X3J11's "changes"
to the language, but nearly everything in ANSI C existed in at least one
production C compiler already, and X3J11 almost always rejected ideas that
were not backed by implementation experience.)
--
Lightweight protocols? TCP/IP *is* | Henry Spencer @ U of Toronto Zoology
lightweight already; just look at OSI. | he...@zoo.toronto.edu utzoo!henry
Charles Hannum
(a) a trailing comma at the end of an enumerator-list is not allowed,
as in:
enum bletch {
foo,
bar,
};
Please note that I am not crusading but simply confused about why I
thought (a) was common usage and (b) was not true.
You've been using Turbo C too much. B-)
Norman Diamond
> as in enum bletch { foo, bar, };
>(b) enum tag namespace is the same as that for struct and union tags
>thought (a) was common usage
Because an extra comma is allowed at the end of an initializer list, which
comes inside the same kind of braces and can look identical in some cases.
The extra comma is allowed at the end of an initializer list because some
programs mechanically generate C code and this saves the work of making
those programs omit the last comma. The extra comma is not allowed at the
end of an enumerator list because no one would ever want to generate those
automatically, or maybe because everyone wants to do the extra work here.
>and (b) was not true.
Probably just intuition, or maybe from using some implementations.
Prior to the standard, implementations had no reason to make enum tags
live in the same space as struct-and-union tags (unless it was convenient
for them). I never thought of testing such possibilities, but some
implementations could have provided separate spaces, and they still could
as extensions (since no strictly conformant program can detect it).
--
Norman Diamond dia...@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
Permission is granted to feel this signature, but not to look at it.
Doug Gwyn
>I am trying to figure out why I previously thought otherwise.
UNIX PCC allowed the comma. The point was debated in committee and there was
enough justification for the trailing comma in struct initializers to sway the
vote in favor of that, but not enough for enums. Personally I think it's an
inconsistent position, but that's what was decided. I have had to edit some
existing code to accommodate this.
I think the name space was simply always that way (e.g. UNIX PCC), but I'm not
100% sure about it.
Tim Olson
|
| (a) a trailing comma at the end of an enumerator-list is not allowed,
| as in:
| enum bletch {
| foo,
| bar,
| };
|
| (b) enum tag namespace is the same as that for struct and union tags
|
| I am trying to figure out why I previously thought otherwise. Of course enums
| were not part of K&R1. I think it may have been the unix v7 C reference
| manual that my understanding of enums was based on but I do not have access to
| a copy now. (It also covered struct arguments and returns.)
|
| Can anyone remind me? Does anyone know if (a) was considered an issue by X3J11
| and whether it is mentioned somewhere in the Rationale?
I seem to remember a debate awhile back, where someone was arguing for
this "feature" for aggregate initialization (i.e. arrays), because it
was easier for automatically-generated initialization lists to always
put the comma at the end of each element (especially if the size is
unknown during generation):
printf("int a[] = {\n");
while (element_list) {
printf("\t%d,\n", element_list->data);
element_list = element_list->next;
}
printf("};\n");
instead of:
printf("int a[] = {\n");
while (element_list) {
if (element_list->next)
printf("\t%d,\n", element_list->data);
else
printf("\t%d\n", element_list->data);
element_list = element_list->next;
}
printf("};\n");
Note that the ANSI Language Syntax Summary *does* allow the trailing
comma for this case (initializer lists). It seems strange not to
allow it for enumerator-lists or struct-declarator lists, as well.
--
-- Tim Olson
Advanced Micro Devices
(t...@amd.com)
Leif Andrew Rump
>In article <10...@labtam.labtam.oz.au> ti...@labtam.labtam.oz.au (Tim Roper) writes:
>>(a) a trailing comma at the end of an enumerator-list is not allowed,
>> as in enum bletch { foo, bar, };
>>(b) enum tag namespace is the same as that for struct and union tags
>>Please note that I am not crusading but simply confused about why I
>>thought (a) was common usage
>Because an extra comma is allowed at the end of an initializer list, which
>comes inside the same kind of braces and can look identical in some cases.
>The extra comma is allowed at the end of an initializer list because some
>programs mechanically generate C code and this saves the work of making
>those programs omit the last comma. The extra comma is not allowed at the
>end of an enumerator list because no one would ever want to generate those
>automatically, or maybe because everyone wants to do the extra work here.
Sorry not true - some of my programs will break! Call me a bad programmer :-(
The construction below allow me to write programs where all the errorcodes
is stored and handled in _one_ file in a consistent way. (there are two problems
with it: it's ugly and when you change the file all your modules recompile!).
It allow me to return an error_t value like CLASSIFY_PARSE_ARGS_DOC_OWNER_ERROR
which may be used in errortext[CLASSIFY_PARSE_ARGS_DOC_OWNER_ERROR] to show me
the text and when I'm finished reading either TERMinate or CONTinue the program
depending on erroraction[CLASSIFY_PARSE_ARGS_DOC_OWNER_ERROR]! Neat(?)
Andrew
/* case_error.h */
typedef enum {CONT, TERM} action_t;
#define errortable \
x(NO_ERROR, TERM, \
"(Should never occur!)") \
x(CLASSIFY_PARSE_ARGS_DOC_NUMBER_MISSING_ERROR, TERM, \
"classify.c (parse_args): Document number missing.") \
x(CLASSIFY_PARSE_ARGS_DOC_PATH_ERROR, TERM, \
"classify.c (parse_args): Document path not defined.") \
x(CLASSIFY_PARSE_ARGS_DOC_PATH_MISSING_ERROR, TERM, \
"classify.c (parse_args): Document path missing.") \
x(CLASSIFY_PARSE_ARGS_DOC_OWNER_ERROR, TERM, \
"classify.c (parse_args): Illegal owner number.") \
x(CLASSIFY_PARSE_ARGS_DOC_OWNER_MISSING_ERROR, TERM, \
"classify.c (parse_args): Document owner missing.") \
/* End errortable */
#define x(name, action, string) name,
typedef enum {
errortable
} error_t;
#undef x
extern char *errortext[]; /* Case/Classify error messages */
extern action_t erroraction[]; /* Case/Classify error actions */
/* case_error.c */
#include "case_error.h"
#define x(name, action, string) string,
char *errortext[] =
{
errortable
};
#undef x
#define x(name, action, string) action,
action_t erroraction[] =
{
errortable
};
#undef x
Leif Andrew Rump, AmbraSoft A/S, Stroedamvej 50, DK-2100 Copenhagen OE, Denmark
UUCP: and...@ambra.dk, phone: +45 39 27 11 77 /
Currently at Scandinavian Airline Systems =======/
UUCP: and...@resam.dk, phone: +45 32 32 51 54 \
SAS, RESAM Project Office, CPHML-V, P.O.BOX 150, DK-2770 Kastrup, Denmark
If it's broke, fix it (The MS-DOS way)
If it aint broke, don't touch it (The Unix way)
If we can't fix it, it ain't broke (Maintainer's Motto)
If you can't fix it, fuck it (The U-boat way)
Kim Christian Madsen
>The extra comma is allowed at the end of an initializer list because some
>programs mechanically generate C code and this saves the work of making
>those programs omit the last comma. The extra comma is not allowed at the
>end of an enumerator list because no one would ever want to generate those
>automatically, or maybe because everyone wants to do the extra work here.
Maybe no one wants to generate enumeration lists automatically, I
doubt, but what about EDITORS, that wants to ease the programmers task
of making nice indentation, like c-mode in GNU emacs... You can say
that the elisp-code is broken yet it's the one distributed and I
prefer:
enum color {
RED, GREEN, BLUE,
};
Instead of the default:
enum color {
RED, GREEN, BLUE
};
Best Regards
Kim Chr. Madsen
Norman Diamond
>In <1991Jul1.0...@tkou02.enet.dec.com> dia...@jit533.swstokyo.dec.com (Norman Diamond) writes:
>>In article <10...@labtam.labtam.oz.au> ti...@labtam.labtam.oz.au (Tim Roper) writes:
>>>(a) a trailing comma at the end of an enumerator-list is not allowed,
>>> as in enum bletch { foo, bar, };
>>>(b) enum tag namespace is the same as that for struct and union tags
>>>Please note that I am not crusading but simply confused about why I
>>>thought (a) was common usage
>>Because an extra comma is allowed at the end of an initializer list, which
>>comes inside the same kind of braces and can look identical in some cases.
[I think this is the reason.]
>>The extra comma is allowed at the end of an initializer list because some
>>programs mechanically generate C code and this saves the work of making
>>those programs omit the last comma.
[This is true.]
>>The extra comma is not allowed at the
>>end of an enumerator list because no one would ever want to generate those
>>automatically, or maybe because everyone wants to do the extra work here.
[This is sarcastic.]
>Sorry not true - some of my programs will break! Call me a bad programmer :-(
Sorry that you missed the sarcasm. Saying "no one would ever want" is
usually sarcastic, because on the occasions when someone says that and
means it, they're usually wrong. However, "everyone wants to do the
extra work" should have made it pretty clear that I was being sarcastic.
>The construction below allow me to write programs where all the errorcodes
>is stored and handled in _one_ file in a consistent way.
Yes, I have wanted to do the same, and I've seen a few other people with
the same wishes. I'm on your side here. My sarcasm did not target you.
Incidentally, the way I solve this for error tables, etc., is to add an
extra identifier at the end of the list. The extra identifier has a
meaningful name such as "number_of_messages", which I then use as a bound
in declaring arrays. If you don't want to use an extra identifier for
anything, then name it "garbage_syntactic_filler_identifier_37".
Norman Diamond
>dia...@jit533.swstokyo.dec.com (Norman Diamond) writes:
>>The extra comma is not allowed at the
>>end of an enumerator list because no one would ever want to generate those
>>automatically, or maybe because everyone wants to do the extra work here.
>
>Maybe no one wants to generate enumeration lists automatically, I
>doubt, but what about EDITORS, that wants to ease the programmers task
I want to. My previous article was sarcastic. Sorry that you missed the
sarcasm. I already explained this in another article; did that article
not get out?