On 1/19/23 22:00, Bastien Roucariès wrote: [...]
<https://inbox.sourceware.org/libc-alpha/0f25d60f-f183-b518-b6c1-6d46aa63ee57@xxxxxxxxx/T/>I do not believe it is broken by design. It should be used with care and warning. BTW if we go to the anonymous union way could we add at the end a _null_reserved_field. It will help for unix socket and the infamous sun_path could not end with null... May be it is too late from an ABI point of view, but for me the posix contract from an ABI point of view is that I said in the note sockaddr_storage could grow but not be reduced.
Yes, many types have seen such additions at the end of it over time. In the Linux man-pages, I try to document all structures as "having at least these members", but may grow over time.
struct sockaddr_storage {
union {
sa_family_t ss_family;
struct sockaddr sa;
struct sockaddr_in sin;
struct sockaddr_in6 sin6;
struct sockaddr_un sun;
};
char __reserved_null;
Such a field would make sense. In fact, I believe the Linux internal implementation of _un must have something similar, since it ensures null-termination even if the user passes a non-terminated string, IIRC.
};
[...]
This is compatible: - It had at least the `ss_family` field. It's still there, at the same binary location. - It has a size at least as large as any other sockaddr_* structure, and a suitable alignment. - Old code still works with it just fine. - New code will be able to avoid UB, and all casts, just by accessing the right structure element. - It's trivial to test at configure time if the implementation provides this new definition of the structure.I agree I could even add a macro for autoconf-archive (I am upstream) and post a patch for gnulib.
Nice; since it's backwards compatible, I'll (probably) suggest a patch for glibc.
+.I sockaddr_storage +structure is large enough to hold any of the other +.I sockaddr_* +variants and always well aligned. On return, it should be cast to the correct +.I sockaddr_*The fact that it is correctly aligned, and a cast will work most of the time, isn't enough for strict aliasing rules. The compiler is free to assume things, just by the fact that it's a different type.Ok any idea for writing this kind of stuffI'm thinking about writing something to several pages; will keep you all updated on important changes to the pages.Please exchange with me... It is really a pitffall for my student, so I could help here.
Sure. Will do. Cheers, Alex
BastienCheers, Alex -- <http://www.alejandro-colomar.es/>
-- <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
