Hi All,
I've found that in many enum lists, there's a comma at the end, e.g.
(arch/x86/kernel/early_printk.c):
enum {
MAGIC1 = 0xBACCD00A,
MAGIC2 = 0xCA110000,
XOPEN = 5,
XWRITE = 4,
};
Just out of curiosity, is there any particular reason here (no word in
CodingStyle about that).
-Jacek
Jacek Luczak writes:
> Hi All,
>
> I've found that in many enum lists, there's a comma at the end, e.g.
> (arch/x86/kernel/early_printk.c):
>
> enum {
> MAGIC1 = 0xBACCD00A,
> MAGIC2 = 0xCA110000,
> XOPEN = 5,
> XWRITE = 4,
> };
>
> Just out of curiosity, is there any particular reason here (no word in
> CodingStyle about that).
Yes. This idiom allows you to add or remove items without
changing adjacent lines.
In a language with strict a comma-as-separator rule you can
get this benefit by placing the comma before new items rather
than after existing items:
enum { FOO
,FIE
,FUM
};
but luckily C doesn't need this perversion.
Jacek Luczak wrote:
> Hi All,
>
> I've found that in many enum lists, there's a comma at the end, e.g.
> (arch/x86/kernel/early_printk.c):
>
> enum {
> MAGIC1 = 0xBACCD00A,
> MAGIC2 = 0xCA110000,
> XOPEN = 5,
> XWRITE = 4,
> };
>
> Just out of curiosity, is there any particular reason here (no word in
> CodingStyle about that).
>
Yes, it's so you can add a line without affecting the line before it,
making a one-line patch into a two-line patch that's more likely to
conflict.
-hpa
Mikael Pettersson pisze:
> Jacek Luczak writes:
> > Hi All,
> >
> > I've found that in many enum lists, there's a comma at the end, e.g.
> > (arch/x86/kernel/early_printk.c):
> >
> > enum {
> > MAGIC1 = 0xBACCD00A,
> > MAGIC2 = 0xCA110000,
> > XOPEN = 5,
> > XWRITE = 4,
> > };
> >
> > Just out of curiosity, is there any particular reason here (no word in
> > CodingStyle about that).
>
> Yes. This idiom allows you to add or remove items without
> changing adjacent lines.
Yep, that's obvious, one line less in diff after every enum change :)
> In a language with strict a comma-as-separator rule you can
> get this benefit by placing the comma before new items rather
> than after existing items:
>
> enum { FOO
> ,FIE
> ,FUM
> };
>
> but luckily C doesn't need this perversion.
>
I was just curious, because it's not common schema (some miss extra comma).
Thanks,
-Jacek
On Sat, Mar 29, 2008 at 10:20:38AM -0700, H. Peter Anvin wrote:
> Jacek Luczak wrote:
> >Hi All,
> >
> >I've found that in many enum lists, there's a comma at the end, e.g.
> >(arch/x86/kernel/early_printk.c):
> >
> >enum {
> > MAGIC1 = 0xBACCD00A,
> > MAGIC2 = 0xCA110000,
> > XOPEN = 5,
> > XWRITE = 4,
> >};
> >
> >Just out of curiosity, is there any particular reason here (no word in
> >CodingStyle about that).
> >
>
> Yes, it's so you can add a line without affecting the line before it,
> making a one-line patch into a two-line patch that's more likely to
> conflict.
Note that doing that makes sense only when you can expect additions to
the end and even then it's a matter of taste.
Al Viro wrote:
> On Sat, Mar 29, 2008 at 10:20:38AM -0700, H. Peter Anvin wrote:
>> Jacek Luczak wrote:
>>> Hi All,
>>>
>>> I've found that in many enum lists, there's a comma at the end, e.g.
>>> (arch/x86/kernel/early_printk.c):
>>>
>>> enum {
>>> MAGIC1 = 0xBACCD00A,
>>> MAGIC2 = 0xCA110000,
>>> XOPEN = 5,
>>> XWRITE = 4,
>>> };
>>>
>>> Just out of curiosity, is there any particular reason here (no word in
>>> CodingStyle about that).
>>>
>> Yes, it's so you can add a line without affecting the line before it,
>> making a one-line patch into a two-line patch that's more likely to
>> conflict.
>
> Note that doing that makes sense only when you can expect additions to
> the end and even then it's a matter of taste.
Yes, it is.
I personally prefer it this way (strongly) for exactly the same reason C
requires a semicolon at the end of each statement, as opposed to Pascal
which doesn't require a semicolon immediately before an "end".
-hpa
Al Viro pisze:
> On Sat, Mar 29, 2008 at 10:20:38AM -0700, H. Peter Anvin wrote:
>> Jacek Luczak wrote:
>>> Hi All,
>>>
>>> I've found that in many enum lists, there's a comma at the end, e.g.
>>> (arch/x86/kernel/early_printk.c):
>>>
>>> enum {
>>> MAGIC1 = 0xBACCD00A,
>>> MAGIC2 = 0xCA110000,
>>> XOPEN = 5,
>>> XWRITE = 4,
>>> };
>>>
>>> Just out of curiosity, is there any particular reason here (no word in
>>> CodingStyle about that).
>>>
>> Yes, it's so you can add a line without affecting the line before it,
>> making a one-line patch into a two-line patch that's more likely to
>> conflict.
>
> Note that doing that makes sense only when you can expect additions to
> the end and even then it's a matter of taste.
>
I think it's hard to ,,expect additions'' or just predict them. But
smaller patch (diff) is one of things that makes sens of adding extra
commas. I'm just pedantic here.
-Jacek
On Saturday 2008-03-29 18:28, H. Peter Anvin wrote:
>>
>> Note that doing that makes sense only when you can expect additions to
>> the end and even then it's a matter of taste.
>
> Yes, it is.
>
> I personally prefer it this way (strongly) for exactly the same
> reason C requires a semicolon at the end of each statement, as
> opposed to Pascal which doesn't require a semicolon immediately
> before an "end".
...as opposed to Perl which does not strictly require a ; at the
end of a block. :>
# while (1) { print 1; print 2 }
On Sat, Mar 29, 2008 at 10:28:26AM -0700, H. Peter Anvin wrote:
> Yes, it is.
>
> I personally prefer it this way (strongly) for exactly the same reason C
> requires a semicolon at the end of each statement, as opposed to Pascal
> which doesn't require a semicolon immediately before an "end".
enum foo {
Foo,
Bar,
Baz,
Max_foo = Baz
};
when you know there won't any additions past the last line (for that matter,
ending it with
Baz,
Sentry_foo,
Max_foo = Sentry_foo - 1
}; is also an option, in which case the end of enum will never be touched
at all).
enum {Some_constant = ...};
when you do not want to mix it with other constants and use a separate
enum for each natural group.
Sometimes it makes sense, sometimes it doesn't. It is an expressive
element, not something to be cast in stone by Documentation/CodingStyle.
Al Viro wrote:
>
> when you know there won't any additions past the last line (for that matter,
> ending it with
> Baz,
> Sentry_foo,
> Max_foo = Sentry_foo - 1
> }; is also an option, in which case the end of enum will never be touched
> at all).
>
Yes, that's a very important exception. Don't put the comma in if you
want the set to be actively closed.
-hpa
On Sat, Mar 29, 2008 at 06:26:33PM +0100, Jacek Luczak wrote:
> I think it's hard to ,,expect additions'' or just predict them.
Depends on the situation.
> But
> smaller patch (diff) is one of things that makes sens of adding extra
> commas. I'm just pedantic here.
Fine, but please let's not turn that into yet another brainless crusade;
we already have enough of those going...
Al Viro wrote:
> Fine, but please let's not turn that into yet another brainless crusade;
> we already have enough of those going...
Amen!
-hpa
Mikael Pettersson <[email protected]> writes:
> In a language with strict a comma-as-separator rule you can
> get this benefit by placing the comma before new items rather
> than after existing items:
>
> enum { FOO
> ,FIE
> ,FUM
> };
>
> but luckily C doesn't need this perversion.
Only since C99 (but GNU C never needed it either).
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Saturday 2008-03-29 19:13, Andreas Schwab wrote:
>> In a language with strict a comma-as-separator rule you can
>> get this benefit by placing the comma before new items rather
>> than after existing items:
>>
>> enum { FOO
>> ,FIE
>> ,FUM
>> };
>>
>> but luckily C doesn't need this perversion.
>
> Only since C99 (but GNU C never needed it either).
C had this for much longer than 99. Borland Turbo C from around 1990
(which you can expect to be C89 if you have luck) also allows , at the end.
Jan Engelhardt <[email protected]> writes:
> On Saturday 2008-03-29 19:13, Andreas Schwab wrote:
>>> In a language with strict a comma-as-separator rule you can
>>> get this benefit by placing the comma before new items rather
>>> than after existing items:
>>>
>>> enum { FOO
>>> ,FIE
>>> ,FUM
>>> };
>>>
>>> but luckily C doesn't need this perversion.
>>
>> Only since C99 (but GNU C never needed it either).
>
> C had this for much longer than 99. Borland Turbo C from around 1990
> (which you can expect to be C89 if you have luck) also allows , at the end.
C89 definitely does not allow a comma at the end of the enumerator list
(only at the end of the initializer list). If Borland C allows it in
its strict C89 mode (if it has such a thing) then it is buggy.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."