pruning a linear singly linked list

[Anando]

Hi,

I have a linear singly linked list of 100 elements. I would like to
prune it [i.e delete some nodes] such that only user specified elements
(say only the elements 1, 13, 78 and 100 of the original list) survive
after pruning.

Can somebody show me how to do this ? I am a scientist and not a
computer engineer/student. This will help me develop an application in
data analysis. I will be grateful for your advice.

Cheers,
Anand.

[Nick Keighley]

Anando wrote:

this is an algorithm (programming technique) question rather
than a strictly C question. Therefore it would be better asked
on comp.programming

I have a linear singly linked list of 100 elements. I would like to
prune it [i.e delete some nodes] such that only user specified elements
(say only the elements 1, 13, 78 and 100 of the original list) survive
after pruning.
life would be easier with a doubly linked list (that only takes another

100 pointer variables with your example). But if you have use a SLL
you'll need to walk two pointers down the list one to point at the
current
node one to point to its predessor. Then chop out the ones you want.
It may make more sense to seek out the required nodes (1, 13, 78, 100)
and copy them to a new list, then destroy the old.
Can somebody show me how to do this ? I am a scientist and not a
computer engineer/student. This will help me develop an application in
data analysis. I will be grateful for your advice.

--
Nick Keighley

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
(Using and Porting GNU CC)

[Anando]

Hi

Thanks for your algorithm. I was thinking of the copy to new list and
destroy old list as well - but when I copied the data it was a shallow
copy (i.e the data in the structure was not copied). Is it possible to
use memcpy or something to copy - if so could you please give a small
example of copying an element such that the data is also copied ?

Many thanks,
Anand.

[Bill Pursell]

Nick Keighley' signature contains:

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.

I would love to see some discussions about this. I'm constantly
changing my mind about whether or not to use extensions. I most
recently decided to start using extensions, marking them with
__extension__, and stop worrying about it. But I keep worrying about
it. At the moment, the only extensions I'm using are trivial-- enums
with trailing commas, unnamed unions within structures (Am I correct in
calling that trivial?), and very rarely the typeof keyword. I work
exclusively with gcc, and although I'm trying to remain within
standards, the only enforcement mechanism I really have is -pedantic,
so for all I know all of my efforts to be completely standard are
wasted. I'd like to start using typeof more often, but am reluctant to
do so. Is there a way to deteremine which extensions are considered
more acceptable (ie more likely to be incorporated into the standard)
than others?

[Ben C]

On 2006-04-23, Bill Pursell <bi**********@gmail.com> wrote:

Nick Keighley' signature contains:

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.

I would love to see some discussions about this. I'm constantly
changing my mind about whether or not to use extensions. I most
recently decided to start using extensions, marking them with
__extension__, and stop worrying about it. But I keep worrying about
it. At the moment, the only extensions I'm using are trivial-- enums
with trailing commas, unnamed unions within structures (Am I correct in
calling that trivial?), and very rarely the typeof keyword. I work
exclusively with gcc, and although I'm trying to remain within
standards, the only enforcement mechanism I really have is -pedantic,

You can use -ansi with gcc, and also -std=c99 or -std=c89

[Flash Gordon]

Ben C wrote:

On 2006-04-23, Bill Pursell <bi**********@gmail.com> wrote:

Nick Keighley' signature contains:

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.

I would love to see some discussions about this. I'm constantly
changing my mind about whether or not to use extensions. I most
recently decided to start using extensions, marking them with
__extension__, and stop worrying about it. But I keep worrying about
it. At the moment, the only extensions I'm using are trivial-- enums
with trailing commas, unnamed unions within structures (Am I correct in
calling that trivial?), and very rarely the typeof keyword. I work
exclusively with gcc, and although I'm trying to remain within
standards, the only enforcement mechanism I really have is -pedantic,

You can use -ansi with gcc, and also -std=c99 or -std=c89

If you want it to attempt to conform to the standard you need both -ansi
(or -std=c89 or -stdc=c99) and -pedantic, however even with that it
still doesn't conform to C99.

Personally I believe one should in general avoid extensions. There are
times when they are required or provide enough benefit to be work it,
but a lot of time they are not.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Nick Keighley]

Bill Pursell wrote:

Nick Keighley' signature contains:

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.

my warped sense of humour catches up with again...

*I* find it amusing that GNU of all "organisations" would be
encouraging
the usage of non-standard extensions. We criticise Microsoft et al for
"extending" standards and hence locking customers in. The same applies
to GNU extensions (and I'm not entirely convinced the motives are any
purer)

I would love to see some discussions about this. I'm constantly
changing my mind about whether or not to use extensions.
I'm at the "extensions are Evil, they rot your teeth, they make your
hair
fall out" end of the spectrum. To be more realistic extensions of some
sort
are always necessary in real world programs. I'd prefer libraries over
compiler extensions and try to confine such extensions to their own
module.
I most recently decided to start using extensions,
just the occaisional use isnt a problem after all you can give up any
time (like heroin :-) )
marking them with __extension__,
eek! That's an identifier in implementation space.
and stop worrying about it. But I keep worrying about
it. At the moment, the only extensions I'm using are trivial-- enums
with trailing commas, unnamed unions within structures (Am I correct in
calling that trivial?),
One I had an argument about was a "flattened" union

So

union A
{
union B
{
int c;
}
};

(apologies if I got the syntax wrong I don't use unions...). With this
extension you could access c with both A.B.c and A.c. The other party
argued "well it's there and it's useful so why not use it?" to my "If
you
can avoid an extension then do so". I work on systems that can outlive
their hardware so I consider this a wise course.

and very rarely the typeof keyword. I work
exclusively with gcc, and although I'm trying to remain within
standards, the only enforcement mechanism I really have is -pedantic,
so for all I know all of my efforts to be completely standard are
wasted. I'd like to start using typeof more often, but am reluctant to
do so. Is there a way to deteremine which extensions are considered
more acceptable (ie more likely to be incorporated into the standard)
than others?

I suppose you could take a look at the standard's comitee stuff. Bear
in mind
that a fair amount of C99 stuff is still not widely available

I recently revived an old program I wrote for Windows. The only problem

was I'd used Turbo C and just tucked in a few extensions... Microsoft
had also discontinued support for some calls. I did get it running
again
but things could have been smoother.
--
Nick Keighley

Programming should never be boring, because anything mundane and
repetitive should be done by the computer.
~Alan Turing

[Andrew Poelstra]

Anando wrote:

Hi

Thanks for your algorithm. I was thinking of the copy to new list and
destroy old list as well - but when I copied the data it was a shallow
copy (i.e the data in the structure was not copied). Is it possible to
use memcpy or something to copy - if so could you please give a small
example of copying an element such that the data is also copied ?

Many thanks,
Anand.

Please remember to quote the post above you; Usenet is not a message board.

Let's assume that you have a struct with 3 variables:
struct data {
int a;
int b;
int c;
}

And within your list you have a pointer to such a struct:
struct data *node;

To memcpy one of these nodes, you must:
1) Allocate the space:
struct data *cp_node = malloc (sizeof (struct data))
if (cp_node == NULL)
{
/* In case you can't get enough memory, do something here */
}

2) Copy it over:
memcpy (cp_node, node, sizeof(struct node);

[Laurijssen]

"Nick Keighley" <ni******************@hotmail.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...

*I* find it amusing that GNU of all "organisations" would be
encouraging
the usage of non-standard extensions. We criticise Microsoft et al for
"extending" standards and hence locking customers in. The same applies
to GNU extensions (and I'm not entirely convinced the motives are any
purer)

many extensions in gcc indeed, i guess gcc being non commercial makes it not
evil :)

[jacob navia]

Nick Keighley a écrit :

Bill Pursell wrote:

I'm at the "extensions are Evil, they rot your teeth, they make your
hair
fall out" end of the spectrum.

Yes but, as you say in the next line:
To be more realistic extensions of some
sort
are always necessary in real world programs.
There you are. Extensions ARE needed, and all languages and improvements
of software were born as extensions of some other stuff.

The C language?

Was an "extension" of BCPL, :-)

C++?

Extension of C

Etc etc.

[snip]
One I had an argument about was a "flattened" union

So

union A
{
union B
{
int c;
}
};

(apologies if I got the syntax wrong I don't use unions...). With this
extension you could access c with both A.B.c and A.c.
This is a very useful extension, one that I have included also in the
lcc-win32 compiler. As you can see useful extensions are that: USEFUL
and they tend to be copied by other compiler, and eventually they make
it into the standard, if the commitee agrees on "existing practice"...
The other party argued "well it's there and it's useful so why not use it?" to my "If
you
can avoid an extension then do so". I work on systems that can outlive
their hardware so I consider this a wise course.

It is a stupid course because:

If you change the layout of the structures you have to modify ALL THOSE
LINES in your code that access that particular field!!!!!

Instead of all that work, your code A.c still works NO MATTER WHERE in
the structure you change the layout!

You understand now?

Extensions are NOT just evil stuff that compiler writers find out to
"lock their users in" but are USEFUL for certain situations!

jacob

[Keith Thompson]

"Bill Pursell" <bi**********@gmail.com> writes:

Nick Keighley' signature contains:

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.

I would love to see some discussions about this. I'm constantly
changing my mind about whether or not to use extensions. I most
recently decided to start using extensions, marking them with
__extension__, and stop worrying about it. But I keep worrying about
it. At the moment, the only extensions I'm using are trivial-- enums
with trailing commas, unnamed unions within structures (Am I correct in
calling that trivial?), and very rarely the typeof keyword.

[snip]

C99 allows a trailing comma on an enumerator list.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[jacob navia]

Keith Thompson a écrit :

C99 allows a trailing comma on an enumerator list.

What was before an extension is now in the standard.

Why?

Because people used the extension, and didn't have the conservative
attitude is promoted here, where any innovation is treated as an heresy,
even in the most trivial cases.

jacob

[Richard Heathfield]

jacob navia said:

Keith Thompson a écrit :

C99 allows a trailing comma on an enumerator list.

What was before an extension is now in the standard.

Why?

No idea. It's a completely pointless extension. The only reason I can think
of for it is consistency with the equally pointless trailing comma on an
initialiser list.

Because people used the extension, and didn't have the conservative
attitude is promoted here, where any innovation is treated as an heresy,
even in the most trivial cases.

No, innovation's great, and it gives you extra choice. But not everybody
innovates in the same way. The conservative attitude promoted here is based
on the fact that using extensions brings with it a portability cost. If you
decide you want to go ahead and use the extensions anyway and let the cost
be hanged, well, that's up to you - and there are newsgroups dealing with
questions about the extensions of particular implementations. Lots of them.
Please let us keep /one/ newsgroup where such extensions are /not/ topical
- pretty please? With sugar on?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Arthur J. O'Dwyer]

On Sun, 23 Apr 2006, Bill Pursell wrote:

Nick Keighley' signature contains:

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
I would love to see some discussions about this. I'm constantly
changing my mind about whether or not to use extensions. I most
recently decided to start using extensions, marking them with
__extension__,

As someone else said, "eek!" But I'm not sure what you mean;
do you mean using the comment string /*__extension__*/ as standard
documentation, the way some people use /*FALLTHROUGH*/ and I
personally use /* Todo fixme bug hack */? Or do you mean naming
your functions things like

fft(x) /* the standard, slow version */
fft__extension__(x) /* the speedy version */

Either of those seems reasonable, although the latter IMHO is a
bad idea.
and stop worrying about it. But I keep worrying about
it. At the moment, the only extensions I'm using are trivial-- enums
with trailing commas, unnamed unions within structures (Am I correct in
calling that trivial?),
If you mean

enum foo { x, y, z, } bar;

struct baz {
union /* unnamed */ {
int i;
double j;
} a;
int b;
};

those are both standard features of C, not extensions. If you mean

struct {
union {
int i; /* henceforth "quux.i" */
double j; /* henceforth "quux.j" */
} /* unnamed */;
int b;
} quux;

that's just wrong and evil, and I didn't even know any implementors
had stooped that low. (For one thing, it means that modifying 'quux.i'
will invalidate 'quux.j', even though they're both syntactically
fields in a struct --- which violates the C "object model" and
generally screws with the maintainer's brain.)
and very rarely the typeof keyword.
'typeof' seems nice, but other than writing SUPER ULTRA FAST!!1!
macros to swap two values of arbitrary type, I've never seen a
real-world use for it. :)
I work
exclusively with gcc, and although I'm trying to remain within
standards, the only enforcement mechanism I really have is -pedantic,
so for all I know all of my efforts to be completely standard are
wasted. I'd like to start using typeof more often, but am reluctant to
do so. Is there a way to deteremine which extensions are considered
more acceptable (ie more likely to be incorporated into the standard)
than others?

Given that the C99 standard still isn't being taught in school, widely
used, or added to GCC, after 7 years, I'm guessing that we may have
reached the point where "likely to be incorporated into the standard"
and "acceptable" are totally different things. As far as I'm concerned,
"acceptable" means either "works in Visual Studio" or "works in ISO C90",
depending on your job description. C99 has nothing to do with it --- let
alone future standards!

my $.02,
-Arthur

[Mark McIntyre]

On Sun, 23 Apr 2006 22:09:47 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

What was before an extension is now in the standard.
Yup.
Why?
Because people used the extension, and didn't have the conservative
attitude is promoted here, where any innovation is treated as an heresy,
even in the most trivial cases.

Or possibly even, because people didn't have MASSIVE chips on their
shoulders about being repeatedly asked not to go on about wildly
offtopic stuff in a group dedicated to a particular topic.

Perhaps you ought to stop making such a complete fool of yourself.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:

Keith Thompson a écrit :

C99 allows a trailing comma on an enumerator list.

What was before an extension is now in the standard.

Why?

Because people used the extension, and didn't have the conservative
attitude is promoted here, where any innovation is treated as an
heresy, even in the most trivial cases.

Jacob, you should know better than this by now.

Extensions are not treated as "heresy". I don't remember anyone other
than you using that word or anything resembling it. I hesitate to
call anyone a liar, but your statement is grossly misleading.

Extensions are treated as exactly what they are -- non-standard
extensions. This newsgroup, as you should know perfectly well,
discusses the C programming language, which is defined by the C90 and
C99 standards. There are a plethora of C implementations, most of
which provide non-standard extensions (as the standard explicitly
allows). We simply lack the expertise and the inclination to keep
track of all of them.

When we see code posted there that uses extensions that are necessary
to the functionality of the code (for example, code that uses
directories or threads), we advise the poster to post to a newsgroup
where those extensions are topical. When we see code that
*unnecessarily* uses extensions (for example, code that gratuitously
clears the screen or calls getch()), we point out that the code is
non-portable, and could easily be made portable.

There are plenty of system-specific newsgroups where these extensions
can be discussed among people who actually know and care about them.

If you want to advocate changes to the standard, comp.std.c is the
place to do so. Actually getting a change through the process is a
lot of work; you can either do that work yourself, or persuade someone
else to do it, or give up. Of course, there's no guarantee that
you'll succeed. If you don't like C as it is, and can't persuade the
committee to change it to your liking, you can always publish your own
language standard, as long as you don't claim that it's C.

If you merely want to discuss or advocate the use of
implementation-specific extensions that you think are useful, please
do so in a newsgroup that's appropriate to the implementation in
question.

You have comp.compilers.lcc, and if you post a brief message here
pointing people to it, I for one will not object. But your repeated
attempts to characterize this newsgroup as some kind of
standard-conforming religious cult are extremely annoying.

Once again, extensions are not evil, and nobody here has claimed that
they are. They're just not what we discuss in this newsgroup.

Do you understand?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Sun, 23 Apr 2006 20:30:13 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

jacob navia said:

Keith Thompson a écrit :

C99 allows a trailing comma on an enumerator list.

What was before an extension is now in the standard.

Why?

No idea. It's a completely pointless extension. The only reason I can think
of for it is consistency with the equally pointless trailing comma on an
initialiser list.

Well, I don't know. I've found a use for it oft-betimes, for example
if you're generating lists via a script, or if you're adding or
recordering elements time to time.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Keith Thompson]

Keith Thompson <ks***@mib.org> writes:

jacob navia <ja***@jacob.remcomp.fr> writes:

Keith Thompson a écrit :

C99 allows a trailing comma on an enumerator list.

What was before an extension is now in the standard.

Why?

Because people used the extension, and didn't have the conservative
attitude is promoted here, where any innovation is treated as an
heresy, even in the most trivial cases.

Jacob, you should know better than this by now.

Extensions are not treated as "heresy". I don't remember anyone other
than you using that word or anything resembling it. I hesitate to
call anyone a liar, but your statement is grossly misleading.

[snip]

The preceding rant was intended for comp.lang.c. I didn't notice that
this thread is cross-posted to comp.programming, where discussions of
non-standard C language extensions might be perfectly topical for all
I know.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Mark McIntyre said:

On Sun, 23 Apr 2006 20:30:13 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalid> wrote:

[...] It's a completely pointless extension. The only reason I can
think of for it is consistency with the equally pointless trailing comma
on an initialiser list.
Well, I don't know. I've found a use for it oft-betimes, for example
if you're generating lists via a script,

That was the original justification for allowing it in the case of the
initialiser, but it's very simple to handle the more restrictive syntax (or
at least, those who do not find it so should possibly not be writing code
generators...).
or if you're adding or
recordering elements time to time.

<shrug> It seems like quite a language wart for such a small benefit.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[CBFalconer]

jacob navia wrote:

Nick Keighley a écrit :

.... snip ...

One I had an argument about was a "flattened" union

So

union A
{
union B
{
int c;
}
};

(apologies if I got the syntax wrong I don't use unions...).
With this extension you could access c with both A.B.c and A.c.

This is a very useful extension, one that I have included also
in the lcc-win32 compiler. As you can see useful extensions are
that: USEFUL and they tend to be copied by other compiler, and
eventually they make it into the standard, if the commitee
agrees on "existing practice"...

No, this is a purposeless extension, only useful to convert
portable code into non-portable code. It doesn't allow you to do
anything you couldn't do without it. As has been said, it "will
make your hair fall out, and will rot your teeth".

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[CBFalconer]

Laurijssen wrote:

"Nick Keighley" <ni******************@hotmail.com> wrote:

*I* find it amusing that GNU of all "organisations" would be
encouraging the usage of non-standard extensions. We criticise
Microsoft et al for "extending" standards and hence locking
customers in. The same applies to GNU extensions (and I'm not
entirely convinced the motives are any purer)

many extensions in gcc indeed, i guess gcc being non commercial
makes it not evil :)

Notwithstanding the fact that some over enthusiastic writers
recommend using those extensions, the fact is that GNU makes it
easy to avoid them and use standards conformant coding practices.
Microsoft makes it hard. I recall that on VC6 one couldn't turn up
the warning level without having the system headers fill the error
messages.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Richard Tobin]

In article <44***************@yahoo.com>,
CBFalconer <cb********@maineline.net> wrote:

With this extension you could access c with both A.B.c and A.c.

No, this is a purposeless extension, only useful to convert
portable code into non-portable code. It doesn't allow you to do
anything you couldn't do without it.

So long as only gcc supports it, it's not very useful, but if it were
more widely adopted it would allow interfaces to be less pointlessly
verbose. As it is, you have to make up a name for something that has
no reason to be named.

-- Richard

[jacob navia]

CBFalconer a écrit :

jacob navia wrote:

Nick Keighley a écrit :

... snip ...

One I had an argument about was a "flattened" union

So

union A
{
union B
{
int c;
}
};

(apologies if I got the syntax wrong I don't use unions...).
With this extension you could access c with both A.B.c and A.c.

This is a very useful extension, one that I have included also
in the lcc-win32 compiler. As you can see useful extensions are
that: USEFUL and they tend to be copied by other compiler, and
eventually they make it into the standard, if the commitee
agrees on "existing practice"...

No, this is a purposeless extension, only useful to convert
portable code into non-portable code. It doesn't allow you to do
anything you couldn't do without it. As has been said, it "will
make your hair fall out, and will rot your teeth".

Of course you avoid any substantial discussion:

What do you do when you have
struct a1 {
struct b {
int a;
}
}

and you change it to:
struct a1 {
struct new {
struct b {
int a;
}
}
}

OF COURSE!!!!

You change ALL your lines in the code from
a.b.a
to
a.new.b.a

Note that you can't do that automatically since you could have
a.b->a
a->b.a
a->b->a
etc.
THAT IS MORE PORTABLE YES!

At what COST ???
No, this is a purposeless extension, only useful to convert
portable code into non-portable code. It doesn't allow you to do
anything you couldn't do without it.

No arguments, no substantive discusion, just assertions without any hint
of WHY should be so.

Let's discuss Chuck for a change. Discussion means exchange of ideas.
Put your ideas forward.

jacob

[CBFalconer]

Mark McIntyre wrote:

Richard Heathfield <in*****@invalid.invalid> wrote:

jacob navia said:

Keith Thompson a écrit :

C99 allows a trailing comma on an enumerator list.

What was before an extension is now in the standard.

Why?

No idea. It's a completely pointless extension. The only reason
I can think of for it is consistency with the equally pointless
trailing comma on an initialiser list.

Well, I don't know. I've found a use for it oft-betimes, for
example if you're generating lists via a script, or if you're
adding or recordering elements time to time.

Pointless. Consider:

enum { thing1
,thing2
,thing3
} thingummies;

which can be easily extended without moving punctuation.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Mark McIntyre]

On Sun, 23 Apr 2006 23:15:52 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

<snip 50 lines of cant>

THAT IS MORE PORTABLE YES!

<snip some more>

you need to learn not to shout, and not to write enormous posts, if
you want people to take you seriously.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[jacob navia]

Mark McIntyre a écrit :

On Sun, 23 Apr 2006 23:15:52 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote:

<snip 50 lines of cant>

THAT IS MORE PORTABLE YES!

<snip some more>

you need to learn not to shout, and not to write enormous posts, if
you want people to take you seriously.
Mark McIntyre

No arguments, no substantive discusion, the same thing as Chuck does.

[Richard Heathfield]

jacob navia said:

What do you do when you have
struct a1 {
struct b {
int a;
}
}

I fix the syntax errors, and move the definition of the inner type out to a
saner level.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[CBFalconer]

jacob navia wrote:

CBFalconer a écrit :
.... snip ...

No, this is a purposeless extension, only useful to convert
portable code into non-portable code. It doesn't allow you to do
anything you couldn't do without it. As has been said, it "will
make your hair fall out, and will rot your teeth".

Of course you avoid any substantial discussion:

.... snip ...
No arguments, no substantive discusion, just assertions without
any hint of WHY should be so.

For the hard of reading, I repeat "It doesn't allow you to do
anything you couldn't do without it". That is, IMNSHO, an adequate
argument for labeling it as "pointless".

Rather than requoting parts of the body of previous messages
multiple times, and spreading things out over pages and pages of
blank screens, I have chosen to snip out the redundancies and let
the essentials speak for themselves. I seem to be able to do this
without even shouting.

If you wish to rebuild the data structures on which your code
depends, then you can alter the structure definitions. I, for one,
am happy that the compiler points out altered usage rather than
going off and quietly making unwarrented assumptions. This
attitude may explain the high level of bug reports for lcc-win
which I note in the lcc newsgroup, and the lack of identification
as to revision, etc. of the whole package.

In case of confusion, I am not happy with your attitude.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Ben Pfaff]

CBFalconer <cb********@yahoo.com> writes:

Mark McIntyre wrote:

Well, I don't know. I've found a use for it oft-betimes, for
example if you're generating lists via a script, or if you're
adding or recordering elements time to time.

Pointless. Consider:

enum { thing1
,thing2
,thing3
} thingummies;

which can be easily extended without moving punctuation.

But it's *ugly*.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Ben Pfaff]

"Arthur J. O'Dwyer" <aj*******@andrew.cmu.edu> writes:

On Sun, 23 Apr 2006, Bill Pursell wrote:

I'm constantly
changing my mind about whether or not to use extensions. I most
recently decided to start using extensions, marking them with
__extension__,

As someone else said, "eek!" But I'm not sure what you mean;
do you mean using the comment string /*__extension__*/ as standard
documentation, [...]

GCC lets you mark use of extensions with __extension__. Here's
one quote from the manual about it:

`-pedantic' and other options cause warnings for many GNU C
extensions. You can prevent such warnings within one
expression by writing `__extension__' before the expression.
`__extension__' has no effect aside from this.

--
"I'm not here to convince idiots not to be stupid.
They won't listen anyway."
--Dann Corbit

[Ben Pfaff]

CBFalconer <cb********@yahoo.com> writes:

Notwithstanding the fact that some over enthusiastic writers
recommend using those extensions, the fact is that GNU makes it
easy to avoid them and use standards conformant coding practices.
Microsoft makes it hard. I recall that on VC6 one couldn't turn up
the warning level without having the system headers fill the error
messages.

It's not a problem with GCC specifically because GCC doesn't
report warnings in the system headers by default (there's an
option you can pass to enable them).
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt

[Bill Pursell]

Ben Pfaff wrote:

But it's *ugly*.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

Now that's ironic. :)

[Bill Pursell]

Arthur J. O'Dwyer wrote:

On Sun, 23 Apr 2006, Bill Pursell wrote:

Nick Keighley' signature contains:

We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
I would love to see some discussions about this. I'm constantly
changing my mind about whether or not to use extensions. I most
recently decided to start using extensions, marking them with
__extension__,

As someone else said, "eek!" But I'm not sure what you mean;
do you mean using the comment string /*__extension__*/ as standard
documentation, the way some people use /*FALLTHROUGH*/ and I
personally use /* Todo fixme bug hack */? Or do you mean naming
your functions things like

The following code generates no errors when compiled with
gcc -Wall -pedantic -ansi:

__extension__ enum {
foo,
bar,
};

int
main(void)
{
return 0;
}

and stop worrying about it. But I keep worrying about
it. At the moment, the only extensions I'm using are trivial-- enums
with trailing commas, unnamed unions within structures (Am I correct in
calling that trivial?),

<snip> struct {
union {
int i; /* henceforth "quux.i" */
double j; /* henceforth "quux.j" */
} /* unnamed */;
int b;
} quux;

that's just wrong and evil, and I didn't even know any implementors
had stooped that low.
gcc allows it. In fact, when marked with __extension__, you don't even
get a complaint with -ansi -pedantic.

and very rarely the typeof keyword.
'typeof' seems nice, but other than writing SUPER ULTRA FAST!!1!
macros to swap two values of arbitrary type, I've never seen a
real-world use for it. :)

My reason for wanting to use it is probably not sound. I dislike
having excessive typedefs, so instead of "typedef uint32_t foo; foo j;
foo j_referrer", I've been tempted to do:
uint32_t j;
typeof(j) j_referrer;
It is purely syntactic sugar, and I think I'll abandon it and use the
typedef.

I work
exclusively with gcc, and although I'm trying to remain within
standards, the only enforcement mechanism I really have is -pedantic,
so for all I know all of my efforts to be completely standard are
wasted. I'd like to start using typeof more often, but am reluctant to
do so. Is there a way to deteremine which extensions are considered
more acceptable (ie more likely to be incorporated into the standard)
than others?

Given that the C99 standard still isn't being taught in school, widely
used, or added to GCC, after 7 years, I'm guessing that we may have
reached the point where "likely to be incorporated into the standard"
and "acceptable" are totally different things. As far as I'm concerned,
"acceptable" means either "works in Visual Studio" or "works in ISO C90",
depending on your job description. C99 has nothing to do with it --- let
alone future standards!

?!?! I thought gcc completely supported c99. I've been using
-std=c99. What aspects are not covered there? We've definitely
strayed off topic on comp.lang.c, so followups should remove it from
the distro.

[Russell Shaw]

Richard Heathfield wrote:

jacob navia said:

Keith Thompson a écrit :

C99 allows a trailing comma on an enumerator list.

What was before an extension is now in the standard.

Why?

No idea. It's a completely pointless extension. The only reason I can think
of for it is consistency with the equally pointless trailing comma on an
initialiser list.

The trailing commas are *very* useful for making algorithmically generated
C code easier.

Because people used the extension, and didn't have the conservative
attitude is promoted here, where any innovation is treated as an heresy,
even in the most trivial cases.

No, innovation's great, and it gives you extra choice. But not everybody
innovates in the same way. The conservative attitude promoted here is based
on the fact that using extensions brings with it a portability cost. If you
decide you want to go ahead and use the extensions anyway and let the cost
be hanged, well, that's up to you - and there are newsgroups dealing with
questions about the extensions of particular implementations. Lots of them.
Please let us keep /one/ newsgroup where such extensions are /not/ topical
- pretty please? With sugar on?

[Russell Shaw]

CBFalconer wrote:

jacob navia wrote:

CBFalconer a écrit :
... snip ...

No, this is a purposeless extension, only useful to convert
portable code into non-portable code. It doesn't allow you to do
anything you couldn't do without it. As has been said, it "will
make your hair fall out, and will rot your teeth".

Of course you avoid any substantial discussion:

... snip ...

No arguments, no substantive discusion, just assertions without
any hint of WHY should be so.

For the hard of reading, I repeat "It doesn't allow you to do
anything you couldn't do without it". That is, IMNSHO, an adequate
argument for labeling it as "pointless".

Then C is pointless, because i can do everything in assembler;)
Rather than requoting parts of the body of previous messages
multiple times, and spreading things out over pages and pages of
blank screens, I have chosen to snip out the redundancies and let
the essentials speak for themselves. I seem to be able to do this
without even shouting.

If you wish to rebuild the data structures on which your code
depends, then you can alter the structure definitions. I, for one,
am happy that the compiler points out altered usage rather than
going off and quietly making unwarrented assumptions. This
attitude may explain the high level of bug reports for lcc-win
which I note in the lcc newsgroup, and the lack of identification
as to revision, etc. of the whole package.

In case of confusion, I am not happy with your attitude.

[Keith Thompson]

"Bill Pursell" <bi**********@gmail.com> writes:
[...]

?!?! I thought gcc completely supported c99. I've been using
-std=c99. What aspects are not covered there? We've definitely
strayed off topic on comp.lang.c, so followups should remove it from
the distro.

<http://gcc.gnu.org/c99status.html>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Russell Shaw <rjshawN_o@s_pam.netspace.net.au> writes:

Richard Heathfield wrote:

jacob navia said:

Keith Thompson a écrit :

C99 allows a trailing comma on an enumerator list.

What was before an extension is now in the standard.

Why?

No idea. It's a completely pointless extension. The only reason I
can think of for it is consistency with the equally pointless
trailing comma on an initialiser list.

The trailing commas are *very* useful for making algorithmically generated
C code easier.

Really? I can see that the trailing comma makes it marginally easier
to generate an enum type declaration, but keeping track of whether a
comma is needed shouldn't be *that* difficult.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

Ben Pfaff wrote:

CBFalconer <cb********@yahoo.com> writes:

Notwithstanding the fact that some over enthusiastic writers
recommend using those extensions, the fact is that GNU makes it
easy to avoid them and use standards conformant coding practices.
Microsoft makes it hard. I recall that on VC6 one couldn't turn
up the warning level without having the system headers fill the
error messages.

It's not a problem with GCC specifically because GCC doesn't
report warnings in the system headers by default (there's an
option you can pass to enable them).

Well of course. However Microshaft, AAIR, did not provide any way
of bypassing the checks on the system headers. One would expect
those to be full of system dependant tricks. Thus the only way to
use Microshaft was without proper checking.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[CBFalconer]

Ben Pfaff wrote:

CBFalconer <cb********@yahoo.com> writes:

Mark McIntyre wrote:

Well, I don't know. I've found a use for it oft-betimes, for
example if you're generating lists via a script, or if you're
adding or recordering elements time to time.

Pointless. Consider:

enum { thing1
,thing2
,thing3
} thingummies;

which can be easily extended without moving punctuation.

But it's *ugly*.

I think it is fairly pretty. But you can always add gargoyles if
you must. The point is that no new and confusing tools are needed.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[jacob navia]

CBFalconer a écrit :

I think it is fairly pretty. But you can always add gargoyles if
you must. The point is that no new and confusing tools are needed.

Please Chuck, what can be confusing in such a simple rule like

"An optional comma is accepted after the last element" ???

If you are confused by THAT I do not see how you can even understand
other, much more complex rules!!!

[suresh]

> Ben Pfaff wrote:

Ben Pfaff wrote:
enum { thing1
,thing2
,thing3
} thingummies;
which can be easily extended without moving punctuation.

But it's *ugly*.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

Now that's ironic. :)

Beauty lies in the beholder of the eye :-)

[jacob navia]

Russell Shaw a écrit :

CBFalconer wrote:

For the hard of reading, I repeat "It doesn't allow you to do
anything you couldn't do without it". That is, IMNSHO, an adequate
argument for labeling it as "pointless".

Then C is pointless, because i can do everything in assembler;)

Well, that is what it runs into... Any small improvement is banned, even
the most simple things like an optional trailing comma in an
enumeration/structure definition are "too much, too confusing"...

And I am not speaking about operator overloading or other heresies.
If we were in the middle ages I would be burned alive. :-)

[Russell Shaw]

Keith Thompson wrote:

Russell Shaw <rjshawN_o@s_pam.netspace.net.au> writes:

Richard Heathfield wrote:

jacob navia said:

Keith Thompson a écrit :

>C99 allows a trailing comma on an enumerator list.
>
What was before an extension is now in the standard.

Why?

No idea. It's a completely pointless extension. The only reason I
can think of for it is consistency with the equally pointless
trailing comma on an initialiser list.

The trailing commas are *very* useful for making algorithmically generated
C code easier.

Really? I can see that the trailing comma makes it marginally easier
to generate an enum type declaration, but keeping track of whether a
comma is needed shouldn't be *that* difficult.

It just makes things mathematically consistant in an algorithm, instead
of having to special-case the first or last entry. When appending or
truncating lists delimited by commas, a whole class of potential comma
bugs is eliminated.

[Nick Keighley]

jacob navia wrote:

Nick Keighley a écrit :

Bill Pursell wrote: I'm at the "extensions are Evil, they rot your teeth, they make your
hair fall out" end of the spectrum.
a little tongue in cheek...

Yes but, as you say in the next line:

To be more realistic extensions of some
sort are always necessary in real world programs.

I submit you can usually keep the *compiler* extensions down to a dull
roar (as opposed to library extensions)
There you are. Extensions ARE needed, and all languages and improvements
of software were born as extensions of some other stuff.

The C language?

Was an "extension" of BCPL, :-)
yes but you were no longer coding BCPL. I'm not against innovation-
I've used
Python I'm looking at Perl. Innovation is good. But if you use every
goody in
your current compiler you may have problems later.

<snip>
One I had an argument about was a "flattened" union

So

union A
{
union B
{
int c;
}
};

(apologies if I got the syntax wrong I don't use unions...). With this
extension you could access c with both A.B.c and A.c.

This is a very useful extension, one that I have included also in the
lcc-win32 compiler. As you can see useful extensions are that: USEFUL

we didn't use it. In fact the compiler documentation *specifically*
warned
against it (it was needed in some system headers).
and they tend to be copied by other compiler, and eventually they make
it into the standard, if the commitee agrees on "existing practice"...

The other party argued "well it's there and it's useful so why not use it?"
to my "If you can avoid an extension then do so". I work on systems
that can outlive their hardware so I consider this a wise course.
It is a stupid course because:

but we got the system running *without* using the extension.
If you change the layout of the structures you have to modify ALL THOSE
LINES in your code that access that particular field!!!!!

Instead of all that work, your code A.c still works NO MATTER WHERE in
the structure you change the layout!
so don't nest structs or unions
You understand now?

Extensions are NOT just evil stuff that compiler writers find out to
"lock their users in" but are USEFUL for certain situations!

but they effectivly lock you in. Every file in a large project I know
has some
#ifdef magic in it because HP and MS do their precompiled headers
differently.

There are some pretty obscure systems out there and your choice of
compilers may be limited. PSos, Telematics-TRAX, VersaDos

When these age and die you port them to Linux. The less compiler
specific stuff you've indulged in the less pain you suffer.

Some day our old Sun based stuff may migrate to Windows. Same
argument. Some systems live a long time and entire technologies can
wax and wane ovwer their lifetime.

So innovate by all means I'll continue to use (and encourage others) to
be cautious with *unneeded* extensions.
--
Nick Keighley

[boa]

CBFalconer wrote:

Ben Pfaff wrote:

CBFalconer <cb********@yahoo.com> writes:

Notwithstanding the fact that some over enthusiastic writers
recommend using those extensions, the fact is that GNU makes it
easy to avoid them and use standards conformant coding practices.
Microsoft makes it hard. I recall that on VC6 one couldn't turn
up the warning level without having the system headers fill the
error messages.

It's not a problem with GCC specifically because GCC doesn't
report warnings in the system headers by default (there's an
option you can pass to enable them).

Well of course. However Microshaft, AAIR, did not provide any way
of bypassing the checks on the system headers. One would expect
those to be full of system dependant tricks. Thus the only way to
use Microshaft was without proper checking.

One tedious way was to use #pragma warning to remove warnings from
system headers. Something like this:

#pragma warning(1234:disable)
#include <windows.h>
#pragma warning(1234:enable)

cl /W4 /WX /c whatever.c
(Haven't done this in some years, so the syntax is probably wrong.)

boa

[Ben Pfaff]

Keith Thompson <ks***@mib.org> writes:

Russell Shaw <rjshawN_o@s_pam.netspace.net.au> writes:

Richard Heathfield wrote:

jacob navia said:

Keith Thompson a icrit :

>C99 allows a trailing comma on an enumerator list.
>
What was before an extension is now in the standard.

Why?
No idea. It's a completely pointless extension. The only reason I
can think of for it is consistency with the equally pointless
trailing comma on an initialiser list.

The trailing commas are *very* useful for making algorithmically generated
C code easier.

Really? I can see that the trailing comma makes it marginally easier
to generate an enum type declaration, but keeping track of whether a
comma is needed shouldn't be *that* difficult.

It is a hassle if you want to use the C preprocessor as your
generator. Consider:

enum {
#ifdef XYZZY
abc,
#endif
#ifdef FUBAR
def,
#endif
};

Now consider how to rewrite this to never end in a comma.
(Adding a sentinel element is the easiest way, but it seems
unclean if you don't otherwise have a use for one.)
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless

[CBFalconer]

jacob navia wrote:

CBFalconer a écrit :

I think it is fairly pretty. But you can always add gargoyles if
you must. The point is that no new and confusing tools are needed.

Please Chuck, what can be confusing in such a simple rule like

"An optional comma is accepted after the last element" ???

If you are confused by THAT I do not see how you can even understand
other, much more complex rules!!!

When you feed such source to a compiler system that doesn't
understand it, and are suddenly faced with pages of errors, you
will regret ever using the silly (and unnecessary) facility. The
aim, from a linguistic viewpoint, should be that there is exactly
one way of achieving any desired goal, and that that way should be
fairly obvious. Real Pascal (not the Borland abortion) more or
less achieves this, C does not.

Adding an extension just to provide a different phrase for saying
the same thing is pointless and foolish. If you consider ways of
parsing the language you will also see the proclivity for further
uncaught errors involved in it.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Richard Tobin]

In article <44***************@yahoo.com>,
CBFalconer <cb********@maineline.net> wrote:

The
aim, from a linguistic viewpoint, should be that there is exactly
one way of achieving any desired goal, and that that way should be
fairly obvious.

"The aim"? Whose aim? It's certainly not a generally accepted aim
among programming language designers.

-- Richard

[tedu]

Richard Heathfield wrote:
[trailing enum comma]

No idea. It's a completely pointless extension. The only reason I can think
of for it is consistency with the equally pointless trailing comma on an
initialiser list.

it also means a diff doesn't have a bonus line removal/addition, which
aids comprehension.

unless, of course, you put the comma first, and i've never seen that in
the wild.

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.edu> writes:

Keith Thompson <ks***@mib.org> writes:

Russell Shaw <rjshawN_o@s_pam.netspace.net.au> writes: [snip]

The trailing commas are *very* useful for making algorithmically generated
C code easier.

Really? I can see that the trailing comma makes it marginally easier
to generate an enum type declaration, but keeping track of whether a
comma is needed shouldn't be *that* difficult.

It is a hassle if you want to use the C preprocessor as your
generator. Consider:

enum {
#ifdef XYZZY
abc,
#endif
#ifdef FUBAR
def,
#endif
};

Now consider how to rewrite this to never end in a comma.
(Adding a sentinel element is the easiest way, but it seems
unclean if you don't otherwise have a use for one.)

Ok, that's a good argument. If the trailing comma were allowed just
for the sake of tools generating C code from scratch, I'd say it's a
silly idea; any decent tool should be able to handle whatever syntax
the language requires. But given this (quite reasonable) idiom of
using #ifdef to control an enum type declaration, allowing a trailing
comma is quite helpful. (And the fact that it makes things *slightly*
easier for code generation tools is a small bonus.)

I'm convinced.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.