Re: Bad interaction between signal constants and -Wsign-conversion

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1706 bytes --]

Hi Vincent,

On 3/30/23 15:59, Vincent Lefevre wrote:
> On 2023-03-29 02:08:39 +0200, Alejandro Colomar via Libc-alpha wrote:
> [about sa_flags in struct sigaction]
>> Well, probably not doable now, but is switching to the unsigned counterpart
>> still possible now?  It would require investigating how this member is
>> being used out there, to know if we're going to break anyones code, and
>> integer conversions are very tricky, so it's hard to know, but for a flags
>> field that is to be used in bitwise operations, I don't expect anyone to
>> actually use it as an int, but rather as an unsigned that for historic
>> reasons happens to be signed.
>>
>> This is also a reminder that new such fields in structures and function
>> parameters should always be of unsigned types if they're going to hold
>> flags (or in general, if they're to be treated as something that requires
>> bitwise operations).
> 
> I entirely agree.
> 
> But concerning struct sigaction in particular, shouldn't this be fixed
> in POSIX?

IMHO, POSIX, and in general, standards, should follow implementations
rather than lead them.  I think changes should start as vendor
extensions.

For example, timespec::tv_nsec was mandated to be long by POSIX and
C11, but glibc used 'long long' in some cases, because it was
necessary.  I would say using 'unsigned int' here would be a nice GNU
extension, and if it proves its value, POSIX could later pick it.

However, as Zack said, I'm not sure how we could check if any programs
out there are using this member unreasonably.

Cheers,

Alex
-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]