No effect of -fshort-enums..is it a bug

No effect of -fshort-enums..is it a bug

[Gaurav Gautam, Noida]

Hi,

I have compiled a testcase

int main()
{
        enum aa {
        a = 0, b =127  , c
        };
 
        printf("size = %d  %d %d\n", sizeof(a),sizeof(b), sizeof(c));
        printf("value= %d  %d %d\n", a,b,c);
        return 0;
}

On gcc (GCC) 4.1.0 20050915 (experimental) with the following option -fshort-enums.

The option -fshort-enums has no effect and the output is same as it is without this option.


I also tried the same tc on gcc (GCC) 3.3.1 (SuSE Linux). But in this case the output changed with and without this option.

I am using an SuSe linux -- X86_AMD64 machine.

I think it's a bug. Can anybody please confirm?

Thanks
Gaurav

Re: No effect of -fshort-enums..is it a bug

[Daniel Jacobowitz]

On Wed, Sep 21, 2005 at 05:46:58PM +0530, Gaurav Gautam, Noida wrote:
> int main()
> {
>         enum aa {
>         a = 0, b =127  , c
>         };
>  
>         printf("size = %d  %d %d\n", sizeof(a),sizeof(b), sizeof(c));
>         printf("value= %d  %d %d\n", a,b,c);
>         return 0;
> }

> The option -fshort-enums has no effect and the output is same as it is without this option.

It's not a bug.  Add sizeof(enum aa) to your printf; _that_ will be
affected by -fshort-enums.  The type of the enumerators remains int.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: No effect of -fshort-enums..is it a bug

[John Love-Jensen]

Hi Gaurav,

You could do this...
q = 4294967295U

Or you could use -std=iso9899:1999 (perhaps with -pedantic) for the compiler
to produce an error.  Assuming you are using GCC 4.x.

Or if you *want* to allow that, you could do this...
-std=gnu99

I'm guessing as to which version of GCC you are using, and what command line
options you used to compile with, and your platform's architecture.

HTH,
--Eljay

RE: No effect of -fshort-enums..is it a bug

[Gaurav Gautam, Noida]

> 
> > Hi Gaurav,
> >
> >> Please confirm which of the two outputs is correct and why is there
a
> > difference in the output of two versions of compiler?
> >
> > Both outputs are "correct".
> >
> 
> 
>   No, the standard is entirely unambiguous:
> 
> --------------------------------------------------------
> 6.4.4.3 Enumeration constants
> Syntax
> 1 enumeration-constant:
> identifier
> Semantics
> 2 An identifier declared as an enumeration constant has type int.
> --------------------------------------------------------
> 
>   The enumeration constants denoted by the identifiers a, b, and c are
> therefore of type int and must have size 4 (on a standard 32-bit
system),
> regardless of the size of the enumerated type aa.

Thank you all for your replies. But I have another question to ask
Consider another example

#include <stdio.h>
int main()
{
  enum ff {
        p = 0, q = 4294967295, r              
        };
        printf("size = %d  %d %d\n", sizeof(enum ff),sizeof(q),
sizeof(r));
        printf("value= %d  %d %d\n", p,q,r);
}

Its output is with default options on gcc :
size = 8  8 8
value= 0  -1 0

Enumerator are supposed to be int and must have size 4. why are they
being treated as long here and taking 8 bytes? Size of int on my machine
is 4.

Also the compiler doesn't even gives a warning when the tc is compiled.
> 
> 
> > (Neither output is compliant to the standard, of course, as -fshort-
> enums
> > is a deviation from the standard.)
> 
>   Nope, the standard is entirely unambiguous:
> 
> --------------------------------------------------------
> 6.7.2.2 Enumeration specifiers
> 
> 4 Each enumerated type shall be compatible with an integer type. The
> choice
> of type is
> implementation-defined,97) but shall be capable of representing the
values
> of all the
> members of the enumeration. The enumerated type is incomplete until
after
> the } that
> terminates the list of enumerator declarations.
> --------------------------------------------------------
> 
>   The choice of what integer type to use to store a value of an
enumerated
> type is implementation-defined, and if a char is big enough to
represent
> all
> the values, the implementation is at liberty to use a char.
> 
> 
> 
>     cheers,
>       DaveK
> --
> Can't think of a witty .sigline today....

Re: No effect of -fshort-enums..is it a bug

[Bernhard R. Link]

* Andreas Schwab <schwab@suse.de> [050921 17:46]:
> "Gaurav Gautam, Noida" <gauravga@noida.hcltech.com> writes:
> > Does -fshort-enum guides the size of enumeration type or the size of
> > enumerator constant ?
> An enumerator constant is not an object, thus it has no size of its own.
> Since the enumerator constants are of type int, not the enum type,
> -fshort-enum should not have any effect on their type.

I think some warning for this case would be nice. While the value is
looks clearly definied, I think almost all cases where this is actually
used will be errors. (The same with sizeof(void), which most likely
only happens with p=malloc(sizeof(*p)) from macros).
Is there already a warning against that (I cannot find any in the info
page) or is there any chance to get such a thing implemented?

Hochachtungsvoll,
	Bernhard R. Link

Re: No effect of -fshort-enums..is it a bug

[Paul Brook]

On Thursday 22 September 2005 19:31, Daniel Jacobowitz wrote:
> On Thu, Sep 22, 2005 at 12:50:39PM -0400, Robert Dewar wrote:
> > of course, but the behavior of a compiler with a special implementation
> > dependent switch is not specified by the standard! Switches can do any
> > amount of violence to the standard you like, the only requirement is
> > that there be a defined set of switches which gives standard defined
> > semantics.
>
> Except that the point I've been trying to make for the last day is that
> -fshort-enums does no damage to the standard.  At least for C99.

It's also worth noting that -fshort-enums is the default on some targets, as 
required by the platform ABI.

Paul

Re: No effect of -fshort-enums..is it a bug

[Daniel Jacobowitz]

On Thu, Sep 22, 2005 at 12:50:39PM -0400, Robert Dewar wrote:
> of course, but the behavior of a compiler with a special implementation
> dependent switch is not specified by the standard! Switches can do any
> amount of violence to the standard you like, the only requirement is
> that there be a defined set of switches which gives standard defined
> semantics.

Except that the point I've been trying to make for the last day is that
-fshort-enums does no damage to the standard.  At least for C99.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: No effect of -fshort-enums..is it a bug

[Robert Dewar]

Dave Korn wrote:
>
>>>Please confirm which of the two outputs is correct and why is there a
>>
>>difference in the output of two versions of compiler?
>>
>>Both outputs are "correct".

>   No, the standard is entirely unambiguous:

of course, but the behavior of a compiler with a special implementation
dependent switch is not specified by the standard! Switches can do any
amount of violence to the standard you like, the only requirement is
that there be a defined set of switches which gives standard defined
semantics.

Re: No effect of -fshort-enums..is it a bug

[Gabriel Dos Reis]

John Love-Jensen <eljay@adobe.com> writes:

| Hi Dave, Daniel, and Gaurav,
| 
| For C99, I stand corrected.
| 
| For C89 or C++98, I think my statement is applicable. 

No, for C++98 your statement is even more incorrect because
enumerators (the constants) are NOT of type int -- and that has been
so for looon time now that I'm surprise.  In fact, I wish the
enumeration underlying type were not int by default.  But I suspect
that for interoperability with C, it was decided -fshort-enum wasn't
the default (I wish it was).

-- Gaby

Re: No effect of -fshort-enums..is it a bug

[John Love-Jensen]

Hi Gaby, Dave, Daniel, and Gaurav,

>This is incorrect and misleading.

I concur.  I retract my previous statement, and direct
seekers-of-clarification to the previous posts that answered this issue.  My
apologies for my confusion.

Sincerely,
--Eljay

Re: No effect of -fshort-enums..is it a bug

[John Love-Jensen]

Hi Dave, Daniel, and Gaurav,

For C99, I stand corrected.

For C89 or C++98, I think my statement is applicable.  (But until I
double-check by reading those standards, take that with a grain of salt.)

For all three, having enum be an int (signed or unsigned) is legit of
course.

For all three, having enum be a long is (at best) a compiler extension, at
worst (-pedantic ?) not supported.  If I'm reading the specs correctly.
NOTE:  not germane to Gaurav's question, just talking out loud.

Sincerely,
--Eljay

Re: No effect of -fshort-enums..is it a bug

[Gabriel Dos Reis]

John Love-Jensen <eljay@adobe.com> writes:

| Hi Gaurav,
| 
| >Please confirm which of the two outputs is correct and why is there a
| difference in the output of two versions of compiler?
| 
| Both outputs are "correct".
| 
| (Neither output is compliant to the standard, of course, as -fshort-enums is
| a deviation from the standard.)

This is incorrect and misleading.

-- Gaby

RE: No effect of -fshort-enums..is it a bug

[Dave Korn]

----Original Message----
>From: John Love-Jensen
>Sent: 22 September 2005 16:34

> Hi Gaurav,
> 
>> Please confirm which of the two outputs is correct and why is there a
> difference in the output of two versions of compiler?
> 
> Both outputs are "correct".
> 


  No, the standard is entirely unambiguous:

--------------------------------------------------------
6.4.4.3 Enumeration constants
Syntax
1 enumeration-constant:
identifier
Semantics
2 An identifier declared as an enumeration constant has type int.
--------------------------------------------------------

  The enumeration constants denoted by the identifiers a, b, and c are
therefore of type int and must have size 4 (on a standard 32-bit system),
regardless of the size of the enumerated type aa.


> (Neither output is compliant to the standard, of course, as -fshort-enums
> is a deviation from the standard.)

  Nope, the standard is entirely unambiguous:

--------------------------------------------------------
6.7.2.2 Enumeration specifiers

4 Each enumerated type shall be compatible with an integer type. The choice
of type is
implementation-defined,97) but shall be capable of representing the values
of all the
members of the enumeration. The enumerated type is incomplete until after
the } that
terminates the list of enumerator declarations.
--------------------------------------------------------

  The choice of what integer type to use to store a value of an enumerated
type is implementation-defined, and if a char is big enough to represent all
the values, the implementation is at liberty to use a char.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: No effect of -fshort-enums..is it a bug

[Daniel Jacobowitz]

On Thu, Sep 22, 2005 at 10:34:19AM -0500, John Love-Jensen wrote:
> Hi Gaurav,
> 
> >Please confirm which of the two outputs is correct and why is there a
> difference in the output of two versions of compiler?
> 
> Both outputs are "correct".
> 
> (Neither output is compliant to the standard, of course, as -fshort-enums is
> a deviation from the standard.)

That's incorrect, please read my response again.  The current output is
C99-conformant.

(It is surprising, though, on many non-embedded targets.  For instance
there are considerable difficulties using this option on GNU/Linux.)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: No effect of -fshort-enums..is it a bug

[John Love-Jensen]

Hi Gaurav,

>Please confirm which of the two outputs is correct and why is there a
difference in the output of two versions of compiler?

Both outputs are "correct".

(Neither output is compliant to the standard, of course, as -fshort-enums is
a deviation from the standard.)

Sincerely,
--Eljay

Re: No effect of -fshort-enums..is it a bug

[Neil Booth]

Gaurav Gautam, Noida wrote:-

>  #include <stdio.h>
>  int main()
>  {
>    enum aa {
>    a = 0, b =127  , c
>    };
> printf("size = %d  %d %d\n", sizeof(enum aa),sizeof(b),sizeof(c));
> printf("value= %d  %d %d\n", a,b,c);
> return 0;
> )
>  
>  The output is
>  size = 1  1 1
>  value= 0  127 128
>  when  gcc (GCC) 3.3.1 (SuSE Linux) is used with -fshort-enums.
>  
>  And
>  
>  size = 1  4 4
>  value= 0  127 128
>  when (GCC) 4.1.0 20050915 (experimental) is used with -fshort-enums.
>  
> Please confirm which of the two outputs is correct and why is there a
> difference in the output of two versions of compiler?

4.1.0 is correct, therefore 3.3.1 was buggy.

Neil.

RE: No effect of -fshort-enums..is it a bug

[Gaurav Gautam, Noida]

Thanks for the reply, but I did not get the answer to my question.
My question is:
In the below mentioned program

 #include <stdio.h>
 int main()
 {
   enum aa {
   a = 0, b =127  , c
   };
printf("size = %d  %d %d\n", sizeof(enum aa),sizeof(b),sizeof(c));
printf("value= %d  %d %d\n", a,b,c);
return 0;
)
 
 The output is
 size = 1  1 1
 value= 0  127 128
 when  gcc (GCC) 3.3.1 (SuSE Linux) is used with -fshort-enums.
 
 And
 
 size = 1  4 4
 value= 0  127 128
 when (GCC) 4.1.0 20050915 (experimental) is used with -fshort-enums.
 
Please confirm which of the two outputs is correct and why is there a
difference in the output of two versions of compiler?

Thanks
Gaurav gautam


> -----Original Message-----
> From: Gaurav Gautam, Noida
> Sent: Wednesday, September 21, 2005 7:04 PM
> To: 'gcc@gcc.gnu.org'; 'gcc-help@gcc.gnu.org'
> Cc: 'Daniel Jacobowitz'
> Subject: RE: No effect of -fshort-enums..is it a bug
> 
> Thanks for the reply,
> 
> But why is there a difference in the output of same tc, with an old
gcc
> compiler and a new version of compiler.
> 
> Was there a bug in the earlier gcc.
> 
> I have a doubt.
> 
> Gcc manual says that
> 
> "-fshort-enums
>     Allocate to an enum type only as many bytes as it needs for the
> declared range of possible values. Specifically, the enum type will be
> equivalent to the smallest integer type which has enough room."
> 
> Does -fshort-enum guides the size of enumeration type or the size of
> enumerator constant ?
> 
> After modifying the tc as
> 
> #include <stdio.h>
> int main()
> {
>         enum aa {
>         a = 0, b =127  , c
>         };
> 
>         printf("size = %d  %d %d\n", sizeof(enum aa),sizeof(b),
> sizeof(c));
>         printf("value= %d  %d %d\n", a,b,c);
> 	  return 0;
> )
> 
> The output is
> 
> size = 1  1 1
> value= 0  127 128
> when  gcc (GCC) 3.3.1 (SuSE Linux) is used with -fshort-enums.
> 
> 
> And
> 
> size = 1  4 4
> value= 0  127 128
> 
> when (GCC) 4.1.0 20050915 (experimental) is used with -fshort-enums.
> 
> Which of the two output is standard confirming.?
> 
> 
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@false.org]
> > Sent: Wednesday, September 21, 2005 6:10 PM
> > To: Gaurav Gautam, Noida
> > Cc: gcc@gcc.gnu.org; gcc-help@gcc.gnu.org
> > Subject: Re: No effect of -fshort-enums..is it a bug
> >
> > On Wed, Sep 21, 2005 at 05:46:58PM +0530, Gaurav Gautam, Noida
wrote:
> > > int main()
> > > {
> > >         enum aa {
> > >         a = 0, b =127  , c
> > >         };
> > >
> > >         printf("size = %d  %d %d\n", sizeof(a),sizeof(b),
sizeof(c));
> > >         printf("value= %d  %d %d\n", a,b,c);
> > >         return 0;
> > > }
> >
> > > The option -fshort-enums has no effect and the output is same as
it is
> > without this option.
> >
> > It's not a bug.  Add sizeof(enum aa) to your printf; _that_ will be
> > affected by -fshort-enums.  The type of the enumerators remains int.
> >
> > --
> > Daniel Jacobowitz
> > CodeSourcery, LLC

Re: No effect of -fshort-enums..is it a bug

[Daniel Jacobowitz]

On Wed, Sep 21, 2005 at 10:54:56AM -0400, Robert Dewar wrote:
> Daniel Jacobowitz wrote:
> >
> >I'm not 100% sure what #3 means for enumerators whose value does not
> >fit in the range of "int", but it's pretty clear that the
> >implementation is not allowed to change the type of enumerators.
> 
> Of course an implementation can do whatever it likes in response
> to switches, compiler dependent declarations etc.

Yes, but -fshort-enums is not intended to interfere with C99
compliance.  And nowadays it doesn't.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: No effect of -fshort-enums..is it a bug

[Andreas Schwab]

"Gaurav Gautam, Noida" <gauravga@noida.hcltech.com> writes:

> Does -fshort-enum guides the size of enumeration type or the size of
> enumerator constant ?

An enumerator constant is not an object, thus it has no size of its own.
Since the enumerator constants are of type int, not the enum type,
-fshort-enum should not have any effect on their type.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: No effect of -fshort-enums..is it a bug

[Robert Dewar]

Daniel Jacobowitz wrote:
>
> I'm not 100% sure what #3 means for enumerators whose value does not
> fit in the range of "int", but it's pretty clear that the
> implementation is not allowed to change the type of enumerators.

Of course an implementation can do whatever it likes in response
to switches, compiler dependent declarations etc.

Re: No effect of -fshort-enums..is it a bug

[Daniel Jacobowitz]

On Wed, Sep 21, 2005 at 07:03:49PM +0530, Gaurav Gautam, Noida wrote:
> Thanks for the reply,
> 
> But why is there a difference in the output of same tc, with an old gcc
> compiler and a new version of compiler. 
> 
> Was there a bug in the earlier gcc.
> 
> I have a doubt.
> 
> Gcc manual says that
> 
> "-fshort-enums
>     Allocate to an enum type only as many bytes as it needs for the
> declared range of possible values. Specifically, the enum type will be
> equivalent to the smallest integer type which has enough room."
> 
> Does -fshort-enum guides the size of enumeration type or the size of
> enumerator constant ?

C99, section 6.7.2.2:

       [#3]  The  identifiers in an enumerator list are declared as
       constants that have type int and may  appear  wherever  such
       are  permitted.

...

       [#4] Each enumerated type shall be compatible with  char,  a
       signed  integer  type,  or  an  unsigned  integer type.  The
       choice  of  type  is  implementation-defined,  but  shall be
       capable of representing the values of all the members of the
       enumeration.

I'm not 100% sure what #3 means for enumerators whose value does not
fit in the range of "int", but it's pretty clear that the
implementation is not allowed to change the type of enumerators.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

RE: No effect of -fshort-enums..is it a bug

[Gaurav Gautam, Noida]

Thanks for the reply,

But why is there a difference in the output of same tc, with an old gcc
compiler and a new version of compiler. 

Was there a bug in the earlier gcc.

I have a doubt.

Gcc manual says that

"-fshort-enums
    Allocate to an enum type only as many bytes as it needs for the
declared range of possible values. Specifically, the enum type will be
equivalent to the smallest integer type which has enough room."

Does -fshort-enum guides the size of enumeration type or the size of
enumerator constant ?

After modifying the tc as 

#include <stdio.h>
int main()
{
        enum aa {
        a = 0, b =127  , c
        };

        printf("size = %d  %d %d\n", sizeof(enum aa),sizeof(b),
sizeof(c));
        printf("value= %d  %d %d\n", a,b,c);
	  return 0;
)

The output is 

size = 1  1 1
value= 0  127 128
when  gcc (GCC) 3.3.1 (SuSE Linux) is used with -fshort-enums.


And 

size = 1  4 4
value= 0  127 128

when (GCC) 4.1.0 20050915 (experimental) is used with -fshort-enums.

Which of the two output is standard confirming.?


> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> Sent: Wednesday, September 21, 2005 6:10 PM
> To: Gaurav Gautam, Noida
> Cc: gcc@gcc.gnu.org; gcc-help@gcc.gnu.org
> Subject: Re: No effect of -fshort-enums..is it a bug
> 
> On Wed, Sep 21, 2005 at 05:46:58PM +0530, Gaurav Gautam, Noida wrote:
> > int main()
> > {
> >         enum aa {
> >         a = 0, b =127  , c
> >         };
> >
> >         printf("size = %d  %d %d\n", sizeof(a),sizeof(b),
sizeof(c));
> >         printf("value= %d  %d %d\n", a,b,c);
> >         return 0;
> > }
> 
> > The option -fshort-enums has no effect and the output is same as it
is
> without this option.
> 
> It's not a bug.  Add sizeof(enum aa) to your printf; _that_ will be
> affected by -fshort-enums.  The type of the enumerators remains int.
> 
> --
> Daniel Jacobowitz
> CodeSourcery, LLC