Re: [PATCH v10 03/26] gunyah: Common types and error codes for Gunyah hypercalls

[Arnd Bergmann]

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