Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > comma at end of initializer allowed?

Reply
Thread Tools

comma at end of initializer allowed?

 
 
Serve Laurijssen
Guest
Posts: n/a
 
      04-20-2004
Is code like the following allowed? I am talking about the comma after the
last function in the initializer.

void f(void) {puts("f");}
void g(void) {puts("g");}

struct Funcs { void (*f[])(void); };

struct Funcs funcs =
{
f,
g,
};

I ask because it makes generating code a lot easier.


 
Reply With Quote
 
 
 
 
Severian
Guest
Posts: n/a
 
      04-20-2004
On Tue, 20 Apr 2004 09:10:49 +0200, "Serve Laurijssen"
<(E-Mail Removed)> wrote:

>Is code like the following allowed? I am talking about the comma after the
>last function in the initializer.
>
>void f(void) {puts("f");}
>void g(void) {puts("g");}
>
>struct Funcs { void (*f[])(void); };
>
>struct Funcs funcs =
>{
>f,
>g,
>};
>
>I ask because it makes generating code a lot easier.
>


I believe it is (and IIRC the rationale was for precisely this
reason). But is it really a big deal to avoid a single if statement,
?: or return buf+x?

I've written lots of code that generates comma-separated lists (and
,\n separated lines, and FF separated pages) that managed to handle
the issue with a few bytes of simple code.
--
Sev
 
Reply With Quote
 
 
 
 
Ike Naar
Guest
Posts: n/a
 
      04-20-2004
Severian <(E-Mail Removed)> wrote:
: On Tue, 20 Apr 2004 09:10:49 +0200, "Serve Laurijssen"
: <(E-Mail Removed)> wrote:
:>Is code like the following allowed? I am talking about the comma after the
:>last function in the initializer.
:>
:>void f(void) {puts("f");}
:>void g(void) {puts("g");}
:>
:>struct Funcs { void (*f[])(void); };
:>
:>struct Funcs funcs =
:>{
:>f,
:>g,
:>};
:>
:>I ask because it makes generating code a lot easier.
:>

Alternatively, you can put a dummy element or a null pointer at the end,
e.g.

struct Funcs funcs =
{
f,
g,
NULL
}
 
Reply With Quote
 
Severian
Guest
Posts: n/a
 
      04-20-2004
On Tue, 20 Apr 2004 11:25:30 GMT, Ike Naar <(E-Mail Removed)>
wrote:

>Severian <(E-Mail Removed)> wrote:
>: On Tue, 20 Apr 2004 09:10:49 +0200, "Serve Laurijssen"
>: <(E-Mail Removed)> wrote:
>:>Is code like the following allowed? I am talking about the comma after the
>:>last function in the initializer.
>:>
>:>void f(void) {puts("f");}
>:>void g(void) {puts("g");}
>:>
>:>struct Funcs { void (*f[])(void); };
>:>
>:>struct Funcs funcs =


I didn't notice late last night, but this obviously needs to be

struct Funcs funcs[] =

>:>{
>:>f,
>:>g,
>:>};
>:>
>:>I ask because it makes generating code a lot easier.
>:>


<I believe IKE snipped something here by accident.>

>Alternatively, you can put a dummy element or a null pointer at the end,
>e.g.
>
> struct Funcs funcs =
> {
> f,
> g,
> NULL
> }


Yes, this is sometimes the appropriate thing to do, if the processing
code is written that way, and if the wasted storage is insignificant.

Sometimes you don't have control over it; a lot of my code to generate
lists is for use in other ways (CSV files, SQL queries, etc.), which
do not allow for excess commas or 'NULL.' It's best to learn good ways
to generate such lists without depending on historical C compiler
allowances. The overhead is so minimal that it can almost always be
ignored.
--
Sev
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      04-20-2004
In <(E-Mail Removed)> Severian <(E-Mail Removed)> writes:

>do not allow for excess commas or 'NULL.' It's best to learn good ways
>to generate such lists without depending on historical C compiler
>allowances.


It's not historical, it's a C89 invention.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Severian
Guest
Posts: n/a
 
      04-20-2004
On 20 Apr 2004 12:49:50 GMT, (E-Mail Removed) (Dan Pop) wrote:

>In <(E-Mail Removed)> Severian <(E-Mail Removed)> writes:
>
>>do not allow for excess commas or 'NULL.' It's best to learn good ways
>>to generate such lists without depending on historical C compiler
>>allowances.

>
>It's not historical, it's a C89 invention.


I may very well be mistaken [1989 was a long time ago on my brief
timeline (b. 1961), I've written millions of lines of code, and I'm
unlikely to spend any time researching the issue], but I remember that
this became part of the standard because many extant C compilers
already accepted the syntax.

I remember it as more a concession to YACC (or some other code
generator) output than anything else.

I know that VAX C (not a great example of a C compiler, but DEC was a
powerful member of the committee) and several PC C compilers handled
it as it was standardized.

(I will have no problem saying "Oops, my bad" if necessary, because
this is totally from memory and I have no emotional attachment to it.)

--
Sev
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      04-20-2004
>On 20 Apr 2004 12:49:50 GMT, (E-Mail Removed) (Dan Pop) wrote:
>>It's not historical, it's a C89 invention.


(Dan is rarely wrong, but I have some vague memory of Dennis'
compilers accepting trailing commas in initializers.)

In article <news:(E-Mail Removed) >
Severian <(E-Mail Removed)> writes (in part):
>I remember it as more a concession to YACC (or some other code
>generator) output than anything else.


This seems unlikely, because PCC (the first YACC-based C compiler)
accepted trailing commas in initializers but not in "enum"s. It
is easy enough to write one's grammar either way.

We might even note that trailing commas were still not valid in
"enum"s in C89 (they finally are, in C99).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
Dan Pop
Guest
Posts: n/a
 
      04-20-2004
In <(E-Mail Removed)> Severian <(E-Mail Removed)> writes:

>On 20 Apr 2004 12:49:50 GMT, (E-Mail Removed) (Dan Pop) wrote:
>
>>In <(E-Mail Removed)> Severian <(E-Mail Removed)> writes:
>>
>>>do not allow for excess commas or 'NULL.' It's best to learn good ways
>>>to generate such lists without depending on historical C compiler
>>>allowances.

>>
>>It's not historical, it's a C89 invention.

>
>I may very well be mistaken [1989 was a long time ago on my brief
>timeline (b. 1961), I've written millions of lines of code, and I'm
>unlikely to spend any time researching the issue], but I remember that
>this became part of the standard because many extant C compilers
>already accepted the syntax.


It turns out I was wrong: it was a standard C feature since "day one",
i.e. since K&R1 was printed. Retained by the standardisation committee
because "it provides flexibility in adding or deleting members from
an initializer list, and simplifies machine generation of such lists".

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: (E-Mail Removed)
 
Reply With Quote
 
Arthur J. O'Dwyer
Guest
Posts: n/a
 
      04-20-2004

On Tue, 20 Apr 2004, Severian wrote:
>
> Ike Naar <(E-Mail Removed)> wrote:
> >Severian <(E-Mail Removed)> wrote:
> >: "Serve Laurijssen" <(E-Mail Removed)> wrote:
> >:> Is code like the following allowed? I am talking about the comma
> >:> after the last function in the initializer.
> >:>
> >:> void f(void) {puts("f");}
> >:> void g(void) {puts("g");}
> >:>
> >:> struct Funcs { void (*f[])(void); };
> >:>
> >:> struct Funcs funcs =

>
> I didn't notice late last night, but this obviously needs to be
>
> struct Funcs funcs[] =


No, it doesn't. Look closely at the typedef for 'Funcs'.
I don't follow C99 weird-array syntax closely enough to tell if
that typedef is legal, but GNU C accepts it with a warning. (This
means it's probably not standard C. Add a '2' inside the '[]' in
the typedef if you want to compile it.)

> >:>{
> >:>f,
> >:>g,
> >:>};


*This*, however, definitely needs to be

{ {f,g,} };

(two pairs of braces). One pair for the struct and an inner pair for
the initializer for the array member.

> >:>
> >:>I ask because it makes generating code a lot easier.


> >Alternatively, you can put a dummy element or a null pointer at the end,
> >e.g.
> >
> > struct Funcs funcs =
> > {
> > f,
> > g,
> > NULL
> > }

>
> Yes, this is sometimes the appropriate thing to do, if the processing
> code is written that way, and if the wasted storage is insignificant.


Just in case you didn't see it (I can't tell from your response),
I think Ike's point was that if your code-generator dumps a bunch
of

xxx,

followed by the string

NULL
}

then you don't have to worry about the extra trailing comma. The
NULL itself can be ignored --- /if the processing code is written
that way/, of course.

> Sometimes you don't have control over it; a lot of my code to generate
> lists is for use in other ways (CSV files, SQL queries, etc.), which
> do not allow for excess commas or 'NULL.' It's best to learn good ways
> to generate such lists without depending on historical C compiler
> allowances. The overhead is so minimal that it can almost always be
> ignored.


Modulo Dan's comments about "historical" (hey, 1989 sounds pretty
historical to *me*! , you're right.

-Arthur
 
Reply With Quote
 
Richard Delorme
Guest
Posts: n/a
 
      04-20-2004
Dan Pop a écrit :
> In <(E-Mail Removed)> Severian <(E-Mail Removed)> writes:
>
>
>>do not allow for excess commas or 'NULL.' It's best to learn good ways
>>to generate such lists without depending on historical C compiler
>>allowances.

>
>
> It's not historical, it's a C89 invention.


C89 belongs to C history.

--
Richard
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
regexp matching end of line or comma Jean-Michel Pichavant Python 1 11-25-2010 06:32 PM
Help with switch configuration, ( 3 3550's, 5 2950's end to end ) ec Cisco 3 07-25-2006 10:30 AM
Measure delay end-to-end Dave Cisco 1 07-20-2004 12:51 PM
is there a difference between CIR and CIR+end to end clear channel connection? ike lozada Cisco 0 05-27-2004 02:34 AM
Initializer and comma seperated lists Pmb C++ 2 05-26-2004 11:49 AM



Advertisments