Re: [PATCH] sockaddr.3type: BUGS: Document that libc should be fixed using a union

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

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

Hello Eric,

On 2/6/23 19:45, Eric Blake wrote:
> On Sun, Feb 05, 2023 at 04:28:36PM +0100, Alejandro Colomar wrote:
> 
> Regardless of the merits of the patch, let's not introduce typos:
> 
>> +++ b/man3type/sockaddr.3type
>> @@ -120,6 +120,26 @@ .SH NOTES
>>   .I <netinet/in.h>
>>   and
>>   .IR <sys/un.h> .
>> +.SH BUGS
>> +.I sockaddr_storage
>> +was designed back when strict aliasing wasn't a problem.
>> +Back then,
>> +one would define a variable of that type,
>> +and then access it as any of the other
>> +.IR sockaddr_ *
>> +types,
>> +depending on the value of the first member.
>> +This is Undefined Behavior.
>> +However, there is no way to use these APIs without invoking Unedfined Behavior,
> 
> Undefined
> 
>> +either in the user program or in libc,
>> +so it is still recommended to use this method.
>> +The only correct way to use different types in an API is through a union.
>> +However,
>> +that union must be implemented in the library,
>> +since the type must be shared between the library and user code,
>> +so libc should be fixed by implementing
>> +.I sockaddr_storage
>> +as a union.
>>   .SH SEE ALSO
>>   .BR accept (2),
>>   .BR bind (2),
> 
> Also, while I could raise the issue with the Austin Group on your
> behalf to get the POSIX wording improved, I think it would work better
> if you initiate a bug report rather than having me do it:
> 
> https://www.austingroupbugs.net/main_page.php

I gave it a try after a year since my last attempt.  The open group website is 
one of the worst I've ever seen.  I'm sorry, I can't get it to work.  Could you 
please report a bug on my behalf?

I have an opengroup account, and supposedly am subscribed to the austin-group-l 
mailing list.  But I'm not able to log it.

Thanks,

Alex

> 

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

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