Hi Bastien and Eric! On 3/18/23 08:54, roucaries bastien wrote: > Hi, > > I have opened a defect at austin group > https://www.austingroupbugs.net/view.php?id=1641 Sorry for not having prepared yet my report as I promised to Eric. I've been busy with other stuff, but still had in mind doing it :). But yes, basically that report is what I would have written, so you have my +1. ;) Cheers, Alex > > Bastien > > Le lun. 6 févr. 2023 à 18:45, Eric Blake <eblake@xxxxxxxxxx> a écrit : >> >> 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 >> >> -- >> Eric Blake, Principal Software Engineer >> Red Hat, Inc. +1-919-301-3266 >> Virtualization: qemu.org | libvirt.org >> -- <http://www.alejandro-colomar.es/> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
