This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM-only [Patch] Allow 4 byte enum size (-fno-short-enums) | Remove hard coded short enum flag from the build scripts?


On 31/08/16 15:33, Richard Earnshaw (lists) wrote:
> On 31/08/16 13:44, Schwarz, Konrad wrote:
>>> -----Original Message-----
>>> From: Richard Earnshaw (lists) [mailto:Richard.Earnshaw@arm.com]
>>> Sent: Wednesday, August 31, 2016 2:38 PM
>>> To: Schwarz, Konrad (CT RDA ITP SES-DE); newlib@sourceware.org
>>> Subject: Re: ARM-only [Patch] Allow 4 byte enum size (-fno-short-enums)
>>> | Remove hard coded short enum flag from the build scripts?
>>
>>
>>>> But wouldn't it suffice to allow the user to select (or override) the
>>>> build attribute to set on the file, e.g., via a compiler command line
>>> switch?
>>>>
>>>
>>> Yes, but 1) we have no builds of GCC available *today* that can do that
>>> and 2) experience has shown that such 'power user' options generally
>>> confuse most users and lead to more problems than they really solve
>>> unless they can validate the user's assertions.
>>>
>>>> Obviously, this requires the compiler to trust the user.
>>>>
>>>> Conversely, as there is no way in (standard) C to distinguish an ABI
>>>> from interfaces internal to the implementation, any scheme to
>>>> determine this build attribute automatically cannot be fully
>>>> satisfactory, no?
>>>>
>>>
>>> No, this is nothing to do with standard C.  The C standard just thinks
>>> about enums at the conceptual level.  It doesn't grubby its hands with
>>> nasty details like ABIs or layout in general...  The idea that this
>>> might be changed in different translation units is completely off-
>>> piste.
>>
>> The corollary being that the only way to do this properly is via a compiler
>> switch, even it is confusing to non-power users.  (Since when has
>> GCC limited itself to the needs of non-power users?)
>>
> 
> I think the best way to do this is using the pragmas I previously
> mentioned.  This gives far more control (power) than the command-line
> switch and has a degree of backward compatibility with some existing
> versions of GCC.
> 
> #define PUSH_PACK_ENUMS _Pragma("GCC push_options") _Pragma ("GCC
> optimize (\"-fshort-enums\")")
> #define POP_PACK_ENUMS _Pragma("GCC pop_options")
> 
> 
> Now some pre-processor testing for support of the GCC pragmas will allow
> us to write
> 
> PUSH_PACK_ENUMS
> enum {a, b, c} w;
> POP_PACK_ENUMS
> 
> int x = sizeof (w);
> 
> enum {
>   d, e, f
> } y;
> 
> int z = sizeof (y);
> 
> Or something like that.
> 


And even cleaner (and working with even more versions of gcc):

#define packed_enum enum __attribute__ ((__packed__))

packed_enum {a, b, c, m=260} w;

int x = sizeof (w);
int t = __alignof(w);

enum {
  d, e, f
} y;

int z = sizeof (y);


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]