On Thu, Mar 2, 2023, at 02:40, Elliot Berman wrote:
> On 2/23/2023 1:58 PM, Alex Elder wrote:
>>> +enum gh_error {
>>> + GH_ERROR_OK = 0,
>>> + GH_ERROR_UNIMPLEMENTED = -1,
>>> + GH_ERROR_RETRY = -2,
>>
>> Do you expect this type to have a particular size?
>> Since you specify negative values, it matters, and
>> it's possible that this forces it to be a 4-byte value
>> (though I'm not sure what the rules are). In other
>> words, UNIMPLEMENTED could conceivably have value 0xff
>> or 0xffffffff. I'm not even sure you can tell whether
>> an enum is interpreted as signed or unsigned.
>
> I'm not a C expert, but my understanding is that enums are signed.
> Gunyah will be returning a signed 64-bit register, however there's no
> intention to go beyond 32 bits of error codes since we want to work on
> 32-bit architectures.
This came up recently because gcc-13 changes the rules.
In GNU C, the enum type will have the smallest type that fits all
values, so if it contains a negative number it ends up as a signed
type (int, long or long long), but if all values are positive and at
least one of them exceeds the signed range (e.g. UINT_MAX), it is
an unsigned type. If it contains both UINT_MAX and -1, the enum
type gets changed to a signed 64-bit type in order to fit both.
Before gcc-13, the individual constants have the smallest type
(at least 'int') that fits their value, but in gcc-13 they have
the same type as the enum type itself.
Arnd
