This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: how to compile enum as signed independent of enum value range?
- From: Ian Lance Taylor <iant at google dot com>
- To: "Michael Brand" <michael dot brand at nexustelecom dot com>
- Cc: <gcc-help at gcc dot gnu dot org>
- Date: 21 Aug 2007 21:19:27 -0700
- Subject: Re: how to compile enum as signed independent of enum value range?
- References: <9556CBAA8C0342489A5161CD96E178954CFD6F@EROS.nexus-ag.com>
"Michael Brand" <michael.brand@nexustelecom.com> writes:
> I expected that it would be possible to do this for enums with a gcc
> option -fsigned-enum like it is possible to do this for bitfieds or char
> with -fsigned-bitfield or -fsigned-char. Shouldn't -fsigned-enum and
> -funsigned-enum be added to gcc to facilitate porting of code to compile
> the same way with gcc too?
According to the C language standard, whether enums are signed or
unsigned is implementation defined. gcc's definitions can be found in
the documentation:
Normally, the type is 'unsigned int' if there are no negative
values in the enumeration, otherwise 'int'. If -fshort-enums is
specified, then if there are negative values it is the first of
'signed char', 'short' and 'int' that can represent all the
values, otherwise it is the first of 'unsigned char', 'unsigned
short' and 'unsigned int' that can represent all the values.
A portable program will only assign enum constants to variables of the
enum type. I think that very few programs would do anything else, and
those programs are inherently unportable. Every option added to gcc
carries a maintenance and documentation cost. I personally don't see
a sufficient reason to add a -fsigned-enum option.
I also tend to think the -funsigned-bitfield option should be removed.
It's a legacy of the days of K&R C, when several popular C compilers
treated bitfields as unsigned even if they weren't declared as such.
Ian