Hi,
I'm just wondering why not declaring errno values using enumaration ? It is
just more convenient when debuging the kernel.
Thanks
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
T?l?chargez cette version sur http://fr.messenger.yahoo.com
On Wed, 23 Nov 2005, moreau francis wrote:
> Hi,
>
> I'm just wondering why not declaring errno values using enumaration ?
> It is just more convenient when debuging the kernel.
>
> Thanks
There is an attempt to keep kernel errno values similar to
user-mode errno values. This simplifies the user-kernel
interface where the kernel will return -ERRNO and the user-mode
code negates it and puts it into the user errno then sets the
return value to -1 (a Unix convention).
The user-mode errno's therefore must correspond. You can't
expect the 'C' runtime libraries to be rebuilt and/or all the
programs recompiled just because the kernel got changed so
the errno's are hard-coded. 0 will always mean "no error" and
1 will always be EPERM, etc. There are error-codes that are
the same number also, EWOULDBLOCK and EAGAIN are examples.
So, you can't just auto-enumerate. If auto-enumeration isn't
possible, then you might just as well use #define, which is
what is done.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Wednesday 23 November 2005 16:19, linux-os (Dick Johnson) wrote:
> > I'm just wondering why not declaring errno values using enumaration ?
> > It is just more convenient when debuging the kernel.
> >
> > Thanks
>
> There is an attempt to keep kernel errno values similar to
> user-mode errno values. This simplifies the user-kernel
> interface where the kernel will return -ERRNO and the user-mode
> code negates it and puts it into the user errno then sets the
> return value to -1 (a Unix convention).
>
> The user-mode errno's therefore must correspond. You can't
> expect the 'C' runtime libraries to be rebuilt and/or all the
> programs recompiled just because the kernel got changed so
> the errno's are hard-coded. 0 will always mean "no error" and
> 1 will always be EPERM, etc. There are error-codes that are
> the same number also, EWOULDBLOCK and EAGAIN are examples.
>
> So, you can't just auto-enumerate. If auto-enumeration isn't
> possible, then you might just as well use #define, which is
> what is done.
?!!
enum {
one,
two,
ten = 10
};
--
vda
On Wednesday 23 November 2005 15:24, moreau francis wrote:
> Hi,
>
> I'm just wondering why not declaring errno values using enumaration ? It is
> just more convenient when debuging the kernel.
Enums are really nice substitute for integer constants instead of #defines.
Enums obey scope rules, #defines do not.
However enums are not widely used because of
1. tradition and style
2. awkward syntax required: enum { ABC = 123 };
Maybe a macro could help
#define CONST(a, N) enaum { a = N }
CONST(ABC, 123);
CONST(DEF, 456);
--
vda
On Wednesday 23 November 2005 15:24, moreau francis wrote:
> Hi,
>
> I'm just wondering why not declaring errno values using enumaration ? It is
> just more convenient when debuging the kernel.
enums are really nice substitute for integer constants instead of
#defines. They obey scope rules. #defines do not.
However enums are not widely used because of
1. tradition and style
2. awkward syntax required: enum { CONST = 1234 };
--
vda
On Mer, 2005-11-23 at 16:31 +0200, Denis Vlasenko wrote:
> Enums are really nice substitute for integer constants instead of #defines.
> Enums obey scope rules, #defines do not.
>
> However enums are not widely used because of
> 1. tradition and style
> 2. awkward syntax required: enum { ABC = 123 };
The SATA layer uses enum for constants and while it was a bit of change
in style when I met it, it does seem to work just as well
On Wed, 23 Nov 2005, Denis Vlasenko wrote:
> On Wednesday 23 November 2005 16:19, linux-os (Dick Johnson) wrote:
>>> I'm just wondering why not declaring errno values using enumaration ?
>>> It is just more convenient when debuging the kernel.
>>>
>>> Thanks
>>
>> There is an attempt to keep kernel errno values similar to
>> user-mode errno values. This simplifies the user-kernel
>> interface where the kernel will return -ERRNO and the user-mode
>> code negates it and puts it into the user errno then sets the
>> return value to -1 (a Unix convention).
>>
>> The user-mode errno's therefore must correspond. You can't
>> expect the 'C' runtime libraries to be rebuilt and/or all the
>> programs recompiled just because the kernel got changed so
>> the errno's are hard-coded. 0 will always mean "no error" and
>> 1 will always be EPERM, etc. There are error-codes that are
>> the same number also, EWOULDBLOCK and EAGAIN are examples.
>>
>> So, you can't just auto-enumerate. If auto-enumeration isn't
>> possible, then you might just as well use #define, which is
>> what is done.
>
> ?!!
>
> enum {
> one,
> two,
> ten = 10
> };
>
> --
Did you BOTHER to read or you just picking a fight??
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
--- Alan Cox <[email protected]> a ?crit :
> On Mer, 2005-11-23 at 16:31 +0200, Denis Vlasenko wrote:
> > Enums are really nice substitute for integer constants instead of #defines.
> > Enums obey scope rules, #defines do not.
> >
> > However enums are not widely used because of
> > 1. tradition and style
> > 2. awkward syntax required: enum { ABC = 123 };
>
> The SATA layer uses enum for constants and while it was a bit of change
> in style when I met it, it does seem to work just as well
>
>
I guess we won't use enumeration because it needs to many changes...Each
function that returns a errno value should have their prototype changed like
this:
int foo(void)
{
int retval;
[...]
return retval;
}
should be changed into
enum errnoval foo(void)
{
enum errnoval retval;
[...]
return retval;
}
Thanks
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
T?l?chargez cette version sur http://fr.messenger.yahoo.com
moreau francis writes:
[...]
>
> I guess we won't use enumeration because it needs to many changes...Each
> function that returns a errno value should have their prototype changed like
> this:
>
> int foo(void)
> {
> int retval;
> [...]
> return retval;
> }
>
> should be changed into
>
> enum errnoval foo(void)
> {
> enum errnoval retval;
> [...]
> return retval;
> }
No it shouldn't. Following is a perfectly legal thing to do in C:
enum side {
LEFT,
RIGHT
};
int foo(int x)
{
if (x & 0x1)
return LEFT;
else
return RIGHT;
}
This is not C++ fortunately.
Nikita.
--- Nikita Danilov <[email protected]> a ?crit :
>
> No it shouldn't. Following is a perfectly legal thing to do in C:
>
> enum side {
> LEFT,
> RIGHT
> };
>
> int foo(int x)
> {
> if (x & 0x1)
> return LEFT;
> else
> return RIGHT;
> }
>
> This is not C++ fortunately.
>
> Nikita.
>
hmm, are you sure that debuggers will tell you that foo returns LEFT/RIGHT but
not any integer value ?
I just give a try and unfortunately you seem to be wrong here:
""""
(gdb) s
foo (x=1) at enum_test.c:8
8 if (x & 0x1)
(gdb) finish
Run till exit from #0 foo (x=1) at enum_test.c:8
0x0804837c in main (argc=1, argv=0xbfe14dc4) at enum_test.c:17
17 return foo(1);
Value returned is $1 = 0
(gdb)
""""
But we needn't change all function prototypes that return an errno value in one
shot because as you said we can mix enum and int.
Thanks
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
T?l?chargez cette version sur http://fr.messenger.yahoo.com
moreau francis writes:
>
[...]
> hmm, are you sure that debuggers will tell you that foo returns
> LEFT/RIGHT but not any integer value ?
No. This is not about debugging, this is about typing.
>
> I just give a try and unfortunately you seem to be wrong here:
I am not, as I never claimed this. :-)
>
> """"
> (gdb) s
> foo (x=1) at enum_test.c:8
> 8 if (x & 0x1)
> (gdb) finish
> Run till exit from #0 foo (x=1) at enum_test.c:8
> 0x0804837c in main (argc=1, argv=0xbfe14dc4) at enum_test.c:17
> 17 return foo(1);
> Value returned is $1 = 0
> (gdb)
(gdb) p (enum side)$1
$2 = LEFT
(This works when debugging information about enum was stored in ELF
object.)
Nikita.
--- Nikita Danilov <[email protected]> a ?crit :
>
> (gdb) p (enum side)$1
> $2 = LEFT
>
> (This works when debugging information about enum was stored in ELF
> object.)
>
not really convenient. For example:
int foo(void)
{
int tmp;
tmp = bar();
[...]
return tmp;
}
How do you know if tmp store an errno value ? You have to look into bar and so
on...By using "enum errnoval", gdb can directly tell you that a variable stores
an errno value.
Thanks
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
T?l?chargez cette version sur http://fr.messenger.yahoo.com
moreau francis writes:
>
[...]
> int foo(void)
> {
> int tmp;
>
> tmp = bar();
> [...]
> return tmp;
> }
>
> How do you know if tmp store an errno value ? You have to look into bar and so
Of course you should. How to debug anything without knowing what called
function is doing? This is kernel programming after all. Which, by the
way, means that debugging convenience is not at all important.
> on...By using "enum errnoval", gdb can directly tell you that a variable stores
> an errno value.
>
> Thanks
Nikita.
Alan Cox wrote:
> On Mer, 2005-11-23 at 16:31 +0200, Denis Vlasenko wrote:
>
>>Enums are really nice substitute for integer constants instead of #defines.
>>Enums obey scope rules, #defines do not.
>>
>>However enums are not widely used because of
>>1. tradition and style
>>2. awkward syntax required: enum { ABC = 123 };
>
>
> The SATA layer uses enum for constants and while it was a bit of change
> in style when I met it, it does seem to work just as well
>
Well, perhaps better, since there is some type checking, and where
auto-increment can be used finger checks don't generate duplicate values
or undefined holes in the value set.
Like the struct definitions vs. old K&R definitions, there is a mental
style adjustment to be made.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Wednesday 23 November 2005 17:00, linux-os (Dick Johnson) wrote:
> On Wed, 23 Nov 2005, Denis Vlasenko wrote:
> > On Wednesday 23 November 2005 16:19, linux-os (Dick Johnson) wrote:
> >>> I'm just wondering why not declaring errno values using enumaration ?
> >>> It is just more convenient when debuging the kernel.
> >>
> >> There is an attempt to keep kernel errno values similar to
> >> user-mode errno values. This simplifies the user-kernel
> >> interface where the kernel will return -ERRNO and the user-mode
> >> code negates it and puts it into the user errno then sets the
> >> return value to -1 (a Unix convention).
> >>
> >> The user-mode errno's therefore must correspond. You can't
> >> expect the 'C' runtime libraries to be rebuilt and/or all the
> >> programs recompiled just because the kernel got changed so
> >> the errno's are hard-coded. 0 will always mean "no error" and
> >> 1 will always be EPERM, etc. There are error-codes that are
> >> the same number also, EWOULDBLOCK and EAGAIN are examples.
> >>
> >> So, you can't just auto-enumerate. If auto-enumeration isn't
> >> possible, then you might just as well use #define, which is
> >> what is done.
> >
> > ?!!
> >
> > enum {
> > one,
> > two,
> > ten = 10
> > };
>
> Did you BOTHER to read or you just picking a fight??
I was trying to say that since enum supports non-contiguous numbering,
any sequence of integer #defines can be trivially converted to enum
declaration:
...
#define ERESTARTSYS 512
#define ERESTARTNOINTR 513
#define ERESTARTNOHAND 514 /* restart if no handler.. */
#define ENOIOCTLCMD 515 /* No ioctl command */
#define ERESTART_RESTARTBLOCK 516 /* restart by calling sys_restart_syscall */
...
enum {
...
ERESTARTSYS = 512,
ERESTARTNOINTR = 513,
ERESTARTNOHAND = 514, /* restart if no handler.. */
ENOIOCTLCMD = 515, /* No ioctl command */
ERESTART_RESTARTBLOCK = 516, /* restart by calling sys_restart_syscall */
...
};
--
vda
On Wednesday 23 November 2005 17:44, moreau francis wrote:
>
> --- Alan Cox <[email protected]> a ?crit :
>
> > On Mer, 2005-11-23 at 16:31 +0200, Denis Vlasenko wrote:
> > > Enums are really nice substitute for integer constants instead of #defines.
> > > Enums obey scope rules, #defines do not.
> > >
> > > However enums are not widely used because of
> > > 1. tradition and style
> > > 2. awkward syntax required: enum { ABC = 123 };
> >
> > The SATA layer uses enum for constants and while it was a bit of change
> > in style when I met it, it does seem to work just as well
>
> I guess we won't use enumeration because it needs to many changes...Each
> function that returns a errno value should have their prototype changed like
> this:
>
> int foo(void)
> {
> int retval;
> [...]
> return retval;
> }
>
> should be changed into
>
> enum errnoval foo(void)
> {
> enum errnoval retval;
> [...]
> return retval;
> }
There exist "unnamed" enums, which do not introduce new type,
just a few symbolic constants of type 'int':
enum /* no name here! */ { A, B, C, D, E };
--
vda
If errno's were an enum type, what would be the type
of the return value of a variety of kernel routines
that now return an int, returning negative errno's on
error and zero or positive values on success?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
Nevermind my question- Looks like moreau francis already noted:
> I guess we won't use enumeration because it needs to many changes...Each
> function that returns a errno value should have their prototype changed
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401
On 23-Nov-2005 Denis Vlasenko wrote:
> On Wednesday 23 November 2005 15:24, moreau francis wrote:
>> Hi,
>>
>> I'm just wondering why not declaring errno values using enumaration ? It is
>> just more convenient when debuging the kernel.
>
> Enums are really nice substitute for integer constants instead of #defines.
> Enums obey scope rules, #defines do not.
>
> However enums are not widely used because of
> 1. tradition and style
> 2. awkward syntax required: enum { ABC = 123 };
The value of an enum constant must be representable as an int. This
is not always the case, expecially with hardware constants and bit
masks, which may require an unsigned int.
--
Giuliano.
moreau francis <[email protected]> writes:
> I'm just wondering why not declaring errno values using enumaration ? It is
> just more convenient when debuging the kernel.
The C standard says that errno values are macros that expand to
integer constant expressions. This is important for userspace,
if not for the kernel.
--
"Then, I came to my senses, and slunk away, hoping no one overheard my
thinking."
--Steve McAndrewSmith in the Monastery
Giuliano Pochini wrote:
> On 23-Nov-2005 Denis Vlasenko wrote:
>
>>On Wednesday 23 November 2005 15:24, moreau francis wrote:
>>
>>>Hi,
>>>
>>>I'm just wondering why not declaring errno values using enumaration ? It is
>>>just more convenient when debuging the kernel.
>>
>>Enums are really nice substitute for integer constants instead of #defines.
>>Enums obey scope rules, #defines do not.
>>
>>However enums are not widely used because of
>>1. tradition and style
>>2. awkward syntax required: enum { ABC = 123 };
>
>
> The value of an enum constant must be representable as an int. This
> is not always the case, expecially with hardware constants and bit
> masks, which may require an unsigned int.
Could you provide an example of where the ERRNO is not an integer? It
doesn't take on bit values, nor can I spot a plcae where the value is so
large it would overflow if signed.
See errno.h for a starting point. I do think error_t is a good idea,
although I doubt there's an example of a type mismatch going uncaught
without it.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
On Thu, 24 Nov 2005, Paul Jackson wrote:
> If errno's were an enum type, what would be the type
> of the return value of a variety of kernel routines
> that now return an int, returning negative errno's on
> error and zero or positive values on success?
>
enums are 'integer types', one of the reasons why #defines
which are also 'integer types' are just as useful. If you
want to auto-increment these integer types, then enums are
useful. Otherwise, just use definitions.
> --
> I won't rest till it's the best ...
> Programmer, Linux Scalability
> Paul Jackson <[email protected]> 1.925.600.0401
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Thursday 01 December 2005 22:01, linux-os (Dick Johnson) wrote:
> On Thu, 24 Nov 2005, Paul Jackson wrote:
>
> > If errno's were an enum type, what would be the type
> > of the return value of a variety of kernel routines
> > that now return an int, returning negative errno's on
> > error and zero or positive values on success?
>
> enums are 'integer types', one of the reasons why #defines
> which are also 'integer types' are just as useful. If you
> want to auto-increment these integer types, then enums are
> useful. Otherwise, just use definitions.
There is another reason why enums are better than #defines:
file.h:
#define foo 123
enum {
bar = 123
};
file.c:
...
#include "something_which_eventually_includes_file.h"
...
int f(int foo, int bar)
{
return foo+bar;
}
Above program has compile-time bug, but it's rather hard
to see it if you are looking at file.c alone.
--
vda
2005/12/2, Denis Vlasenko <[email protected]>:
> On Thursday 01 December 2005 22:01, linux-os (Dick Johnson) wrote:
> > On Thu, 24 Nov 2005, Paul Jackson wrote:
> >
> > > If errno's were an enum type, what would be the type
> > > of the return value of a variety of kernel routines
> > > that now return an int, returning negative errno's on
> > > error and zero or positive values on success?
> >
> > enums are 'integer types', one of the reasons why #defines
> > which are also 'integer types' are just as useful. If you
> > want to auto-increment these integer types, then enums are
> > useful. Otherwise, just use definitions.
>
> There is another reason why enums are better than #defines:
This is a reason why enums are worse than #defines.
Unlike in other languages, C enum is not much useful in practices.
Maybe the designer wanted C to be as fancy as other languages? C
shouldn't have had enum imho. Anyway we don't have any strong motives
to switch to enums.
>
> file.h:
> #define foo 123
> enum {
> bar = 123
> };
>
>
> file.c:
> ...
> #include "something_which_eventually_includes_file.h"
> ...
> int f(int foo, int bar)
> {
> return foo+bar;
> }
>
> Above program has compile-time bug, but it's rather hard
> to see it if you are looking at file.c alone.
> --
> vda
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
On Friday 02 December 2005 11:27, Coywolf Qi Hunt wrote:
> 2005/12/2, Denis Vlasenko <[email protected]>:
> > On Thursday 01 December 2005 22:01, linux-os (Dick Johnson) wrote:
> > > On Thu, 24 Nov 2005, Paul Jackson wrote:
> > >
> > > > If errno's were an enum type, what would be the type
> > > > of the return value of a variety of kernel routines
> > > > that now return an int, returning negative errno's on
> > > > error and zero or positive values on success?
> > >
> > > enums are 'integer types', one of the reasons why #defines
> > > which are also 'integer types' are just as useful. If you
> > > want to auto-increment these integer types, then enums are
> > > useful. Otherwise, just use definitions.
> >
> > There is another reason why enums are better than #defines:
>
> This is a reason why enums are worse than #defines.
Why?
> > file.c:
> > ...
> > #include "something_which_eventually_includes_file.h"
> > ...
> > int f(int foo, int bar)
> > {
> > return foo+bar;
> > }
This gets converted to "int f(int 123, int bar)" when foo
is a #define. Do you disagree that it is bad?
--
vda
Hi,
2005/12/2, Denis Vlasenko <[email protected]>:
> > There is another reason why enums are better than #defines:
On 12/2/05, Coywolf Qi Hunt <[email protected]> wrote:
> This is a reason why enums are worse than #defines.
>
> Unlike in other languages, C enum is not much useful in practices.
> Maybe the designer wanted C to be as fancy as other languages? C
> shouldn't have had enum imho. Anyway we don't have any strong motives
> to switch to enums.
I don't follow your reasoning. The naming collision is a real problem
with macros. With enum and const, the compiler can do proper checking
with meaningful error messages. Please explain why you think #define
is better for Denis' example?
Pekka
2005/12/2, Pekka Enberg <[email protected]>:
> Hi,
>
> 2005/12/2, Denis Vlasenko <[email protected]>:
> > > There is another reason why enums are better than #defines:
>
> On 12/2/05, Coywolf Qi Hunt <[email protected]> wrote:
> > This is a reason why enums are worse than #defines.
> >
> > Unlike in other languages, C enum is not much useful in practices.
> > Maybe the designer wanted C to be as fancy as other languages? C
> > shouldn't have had enum imho. Anyway we don't have any strong motives
> > to switch to enums.
>
> I don't follow your reasoning. The naming collision is a real problem
> with macros. With enum and const, the compiler can do proper checking
> with meaningful error messages. Please explain why you think #define
> is better for Denis' example?
>
> Pekka
>
That is a bad bad style. It should be `#define FOO 123' if you have to
write it.
It's also hard to see what the confusing bar is "if you are looking at
file.c alone".
enum is worse than typdef. Don't you see why we should use `struct
task_struct', rather than `task_t'?
Introducing enum alone can't solve the problems from bad macro usage
habits. Actually, it's not anything wrong with macros, it's
programers' bad coding style.
Macros play an important role in C, but enums don't.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
On Friday 02 December 2005 14:56, Coywolf Qi Hunt wrote:
> 2005/12/2, Pekka Enberg <[email protected]>:
> > Hi,
> >
> > 2005/12/2, Denis Vlasenko <[email protected]>:
> > > > There is another reason why enums are better than #defines:
> >
> > On 12/2/05, Coywolf Qi Hunt <[email protected]> wrote:
> > > This is a reason why enums are worse than #defines.
> > >
> > > Unlike in other languages, C enum is not much useful in practices.
> > > Maybe the designer wanted C to be as fancy as other languages? C
> > > shouldn't have had enum imho. Anyway we don't have any strong motives
> > > to switch to enums.
> >
> > I don't follow your reasoning. The naming collision is a real problem
> > with macros. With enum and const, the compiler can do proper checking
> > with meaningful error messages. Please explain why you think #define
> > is better for Denis' example?
> >
> > Pekka
>
> That is a bad bad style. It should be `#define FOO 123' if you have to
> write it.
I suspect this style was invented exactly as a device to stop confusing
macro names with variable/function names.
> It's also hard to see what the confusing bar is "if you are looking at
> file.c alone".
int f(int foo, int bar) {...}
bar is a parameter of type "int" of function f(). What else it could be here?
It's basic C.
> enum is worse than typdef. Don't you see why we should use `struct
> task_struct', rather than `task_t'?
>
> Introducing enum alone can't solve the problems from bad macro usage
> habits. Actually, it's not anything wrong with macros, it's
> programers' bad coding style.
>
> Macros play an important role in C, but enums don't.
Looks more like your personal dislike to enum keyword.
--
vda
2005/12/2, Pekka Enberg <[email protected]>:
> > I don't follow your reasoning. The naming collision is a real problem
> > with macros. With enum and const, the compiler can do proper checking
> > with meaningful error messages. Please explain why you think #define
> > is better for Denis' example?
On Fri, 2005-12-02 at 20:56 +0800, Coywolf Qi Hunt wrote:
> That is a bad bad style. It should be `#define FOO 123' if you have to
> write it.
Fair enough. And when you have two colliding constants, macros are
superior, because...?
Pekka
Coywolf Qi Hunt wrote:
> 2005/12/2, Pekka Enberg <[email protected]>:
>
>>Hi,
>>
>>2005/12/2, Denis Vlasenko <[email protected]>:
>>
>>>>There is another reason why enums are better than #defines:
>>
>>On 12/2/05, Coywolf Qi Hunt <[email protected]> wrote:
>>
>>>This is a reason why enums are worse than #defines.
>>>
>>>Unlike in other languages, C enum is not much useful in practices.
>>>Maybe the designer wanted C to be as fancy as other languages? C
>>>shouldn't have had enum imho. Anyway we don't have any strong motives
>>>to switch to enums.
>>
>>I don't follow your reasoning. The naming collision is a real problem
>>with macros. With enum and const, the compiler can do proper checking
>>with meaningful error messages. Please explain why you think #define
>>is better for Denis' example?
>>
>> Pekka
>>
>
>
> That is a bad bad style. It should be `#define FOO 123' if you have to
> write it.
>
> It's also hard to see what the confusing bar is "if you are looking at
> file.c alone".
>
> enum is worse than typdef. Don't you see why we should use `struct
> task_struct', rather than `task_t'?
>
> Introducing enum alone can't solve the problems from bad macro usage
> habits. Actually, it's not anything wrong with macros, it's
> programers' bad coding style.
Using enum doesn't *solve* problems, it does *allow* type checking, and
*prevent* namespace pollution. Use of typedef allows future changes, if
you use "struct XXX" you're stuck with it.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Coywolf Qi Hunt wrote:
> This is a reason why enums are worse than #defines.
>
> Unlike in other languages, C enum is not much useful in practices.
Actually they are highly useful if you know how to use them. They allow
type checking, have auto increment, and are part of the language instead
of a feature of the preprocessor.
> Maybe the designer wanted C to be as fancy as other languages? C
> shouldn't have had enum imho. Anyway we don't have any strong motives
> to switch to enums.
The last sentence seems correct in spite of your misunderstanding of how
and why enums are used and useful. Like a driver who mis-read a map
wandering aimlessly and lost, you have come to the correct destination
by accident.
> --
> Coywolf Qi Hunt
> http://sosdg.org/~coywolf/
It would have been good to use enums in the first place, I can't see
changing now because of the effort involved.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
2005/12/3, Bill Davidsen <[email protected]>:
> Using enum doesn't *solve* problems, it does *allow* type checking, and
> *prevent* namespace pollution. Use of typedef allows future changes, if
> you use "struct XXX" you're stuck with it.
Yes, Greg KH had a lecture at a KS to encourage us to "stuck with it".
And akpm once told me to always use struct foo * when I was trying to
use task_t in argument list and struct task_struct *.for variable
definitions.
What do you mean by `future change'? You constantly change the struct
name or its members? I don't see any real problem hier.
>
> --
> bill davidsen <[email protected]>
> CTO TMR Associates, Inc
> Doing interesting things with small computers since 1979
>
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
On Fri, 2 Dec 2005, Bill Davidsen wrote:
> Coywolf Qi Hunt wrote:
> >
> > That is a bad bad style. It should be `#define FOO 123' if you have to
> > write it.
> >
> > It's also hard to see what the confusing bar is "if you are looking at
> > file.c alone".
> >
> > enum is worse than typdef. Don't you see why we should use `struct
> > task_struct', rather than `task_t'?
> >
> > Introducing enum alone can't solve the problems from bad macro usage
> > habits. Actually, it's not anything wrong with macros, it's
> > programers' bad coding style.
>
> Using enum doesn't *solve* problems, it does *allow* type checking, and
> *prevent* namespace pollution. Use of typedef allows future changes, if
> you use "struct XXX" you're stuck with it.
You're not stuck with anything onerous in this case. Namely,
If you have "enum XXX" and you want to go to "enum YYY", then...
sed 's/enum XXX/enum YYY/g'
If you have "struct XXX" and you want to go to "struct YYY", then...
sed 's/struct XXX/struct YYY/g'
If you have "enum XXX" and you want to go to "struct YYY", then...
This is a big change, and should be done with care anyway. If struct YYY
happens to be large, then suddenly you can get all sorts of nifty stack
overflows.
In general, code that does not typedef enums and structs unless
absolutely necessary is easier to work with for these reasons:
1) The type of the variable is very obvious from its 'name', without the
uglyness that is Hungarian notation.
2) You don't need to include definition (such as from a header file)
just to declare a pointer to the type. Cuts down on #include clutter.
3) The enum namespace is separate from the struct namespace, which is
separate from other namespaces. Less naming collisions.
YMMV; not an invitation to start a coding style religious war
> --
> bill davidsen <[email protected]>
> CTO TMR Associates, Inc
> Doing interesting things with small computers since 1979
> -
-Vadim Lobanov
2005/12/3, Bill Davidsen <[email protected]>:
> Coywolf Qi Hunt wrote:
>
> > This is a reason why enums are worse than #defines.
> >
> > Unlike in other languages, C enum is not much useful in practices.
>
> Actually they are highly useful if you know how to use them. They allow
> type checking, have auto increment, and are part of the language instead
> of a feature of the preprocessor.
Yes, I know type checking and auto increment. But they are not
worthwhile, at least not for serious C programming. No, I don't know
how to use them comfortably.
What's wrong with sorted macros? They are more flexible and readable.
enums just look weird. We also share macros b/w C and asm.
You words on language and preprocessor doesn't make any sense.
It's not a feature of the preprocessor, it's what cpp is for. Look, I
call it Cpp. Without this `feature', what would a C preprocessor do?
You've castrated cpp.
Follow you logic, C standard should only specify C language, not
anything of libc... I have no interest in arguing the relations b/w C
and cpp.
>
> > Maybe the designer wanted C to be as fancy as other languages? C
> > shouldn't have had enum imho. Anyway we don't have any strong motives
> > to switch to enums.
>
> The last sentence seems correct in spite of your misunderstanding of how
> and why enums are used and useful. Like a driver who mis-read a map
> wandering aimlessly and lost, you have come to the correct destination
> by accident.
lol
>
> It would have been good to use enums in the first place, I can't see
> changing now because of the effort involved.
You contradict yourself rather.
--
Coywolf Qi Hunt
http://sosdg.org/~coywolf/
I'm going to regret jumping in on this.
On Sat, 2005-12-03 at 01:07 +0800, Coywolf Qi Hunt wrote:
> 2005/12/3, Bill Davidsen <[email protected]>:
> > Coywolf Qi Hunt wrote:
> >
> > > This is a reason why enums are worse than #defines.
> > >
> > > Unlike in other languages, C enum is not much useful in practices.
> >
> > Actually they are highly useful if you know how to use them. They allow
> > type checking, have auto increment, and are part of the language instead
> > of a feature of the preprocessor.
>
> Yes, I know type checking and auto increment. But they are not
> worthwhile, at least not for serious C programming. No, I don't know
> how to use them comfortably.
Hmm, I like to use a lot of both enums and macros (defines). I use
defines mostly for general constants and emums for enumerations.
Although it can be argued that errno should be enums, I would prefer
them as macros. Especially since they then can be used in asm. (.S
files).
I seldom use enums for kernel programming though. I use it just to
define a list of numbers where I don't care what their value is (usually
for transition states). I use defines when I do. Because errno does
depend on the value (for glibc to figure them out too) then I think
defines are better.
But in user space programming I use enums more often than defines,
because gdb can convert the number into a name. So instead of seeing
x=0x1234 I see x=FOO.
-- Steve
Coywolf Qi Hunt wrote:
>2005/12/3, Bill Davidsen <[email protected]>:
>
>
>>Coywolf Qi Hunt wrote:
>>
>>
>>
>>>This is a reason why enums are worse than #defines.
>>>
>>>Unlike in other languages, C enum is not much useful in practices.
>>>
>>>
>>Actually they are highly useful if you know how to use them. They allow
>>type checking, have auto increment, and are part of the language instead
>> of a feature of the preprocessor.
>>
>>
>
>Yes, I know type checking and auto increment. But they are not
>worthwhile, at least not for serious C programming. No, I don't know
>how to use them comfortably.
>
>
Type checking is not useful for serious C programming? Really?
>What's wrong with sorted macros? They are more flexible and readable.
>enums just look weird. We also share macros b/w C and asm.
>
>You words on language and preprocessor doesn't make any sense.
>
>
They highlight the difference. The preprocessor is a form of text
editor, which only knows what the source *says* but not what it *means*.
The compiler knows about types, common subexpressions, etc.
>It's not a feature of the preprocessor, it's what cpp is for. Look, I
>call it Cpp. Without this `feature', what would a C preprocessor do?
>You've castrated cpp.
>
>Follow you logic, C standard should only specify C language, not
>anything of libc... I have no interest in arguing the relations b/w C
>and cpp.
>
>
The standard should specify the source language and it's meaning. The
fact that it specifies what cpp does (text editing) as well is for
convenience. The language works the same whether you write it with vi or
cpp, cpp is just more convenient that sed ;-)
>
>
>>>Maybe the designer wanted C to be as fancy as other languages? C
>>>shouldn't have had enum imho. Anyway we don't have any strong motives
>>>to switch to enums.
>>>
>>>
>>The last sentence seems correct in spite of your misunderstanding of how
>>and why enums are used and useful. Like a driver who mis-read a map
>>wandering aimlessly and lost, you have come to the correct destination
>>by accident.
>>
>>
>
>lol
>
>
>
>>It would have been good to use enums in the first place, I can't see
>>changing now because of the effort involved.
>>
>>
>
>You contradict yourself rather.
>
>
Not at all... enum would have been better, but not so much better that
it's worth doing over.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Coywolf Qi Hunt <[email protected]> wrote:
> 2005/12/3, Bill Davidsen <[email protected]>:
> > Coywolf Qi Hunt wrote:
> > > This is a reason why enums are worse than #defines.
> > >
> > > Unlike in other languages, C enum is not much useful in practices.
> > Actually they are highly useful if you know how to use them. They allow
> > type checking, have auto increment, and are part of the language instead
> > of a feature of the preprocessor.
The preprocessor /is/ part lof the language...
> Yes, I know type checking and auto increment. But they are not
> worthwhile, at least not for serious C programming.
They do have their uses. No, C (particularly as used today) is not a
"designed" language, it has several ways of doing the same thing, some
quirks, and outright design mistakes.
> No, I don't know
> how to use them comfortably.
Then you aren't fit to judge, are you?
> What's wrong with sorted macros? They are more flexible
"More flexible" == "more leeway to screw up"...
> and readable.
"Readable" is in the eye of the beholder...
> enums just look weird.
Ditto.
> We also share macros b/w C and asm.
So what?
[...]
> Follow you logic, C standard should only specify C language, not
> anything of libc... I have no interest in arguing the relations b/w C
> and cpp.
libc is part of the language, as is cpp.
[...]
> > It would have been good to use enums in the first place, I can't see
> > changing now because of the effort involved.
> You contradict yourself rather.
No. The difference between them is not /that/ large, and by now the use of
#define is so much part of the "way things are done" that the pain of
changing it doesn't buy you enough.
What I see is that you don't know too much about large-scale software
development (and Linux is definitively in that league).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Friday 02 December 2005 18:56, Vadim Lobanov wrote:
> On Fri, 2 Dec 2005, Bill Davidsen wrote:
>
> > Coywolf Qi Hunt wrote:
> > >
> > > That is a bad bad style. It should be `#define FOO 123' if you have to
> > > write it.
> > >
> > > It's also hard to see what the confusing bar is "if you are looking at
> > > file.c alone".
> > >
> > > enum is worse than typdef. Don't you see why we should use `struct
> > > task_struct', rather than `task_t'?
> > >
> > > Introducing enum alone can't solve the problems from bad macro usage
> > > habits. Actually, it's not anything wrong with macros, it's
> > > programers' bad coding style.
> >
> > Using enum doesn't *solve* problems, it does *allow* type checking, and
> > *prevent* namespace pollution. Use of typedef allows future changes, if
> > you use "struct XXX" you're stuck with it.
>
> You're not stuck with anything onerous in this case. Namely,
>
> If you have "enum XXX" and you want to go to "enum YYY", then...
> sed 's/enum XXX/enum YYY/g'
> If you have "struct XXX" and you want to go to "struct YYY", then...
> sed 's/struct XXX/struct YYY/g'
> If you have "enum XXX" and you want to go to "struct YYY", then...
> This is a big change, and should be done with care anyway. If struct YYY
> happens to be large, then suddenly you can get all sorts of nifty stack
> overflows.
I was talking about _anonymous enums_. There you do not have enum XXX,
you have only named constants of type int:
enum { CONST = 12345 };
CONST is of type "int" here.
--
vda