On 4/21/23 16:58, Alejandro Colomar wrote:
> Hi Eric,
> 
> On 4/14/23 18:08, Zack Weinberg via Libc-alpha wrote:
>> On 2023-04-06 3:37 PM, Eric Blake wrote:
>>> Since Issue 7 is tied to C99, and Issue 8 will be tied to C17, both of
>>> which use the same section number despite being a different edition of
>>> the C standard, being that specific may work.  Or, we might try
>>> something focusing more on wording instead of document location, as
>>> in:
>>>
>>> Additionally, the structures shall be defined in such a way that the
>>> compiler treats an access to the stored value of the sa_family_t
>>> member of any of these structures, via an lvalue expression whose type
>>> involves any other one of these structures, as permissible even if the
>>> types involved would not otherwise be deemed compatible with the
>>> effective type of the object ultimately being accessed.
> 
> The wording I see in <https://austingroupbugs.net/view.php?id=1641#c6262>
> doesn't seem to cover the case of aliasing a sockaddr_storage as a
> protocol-specific address for setting other members.
> 
> Aliasing rules don't allow one to declare an object of type
> sockaddr_storage and then fill the structure as if it were another
> structure, even if alignment and size are correct.  We would need
> some wording that says something like:
> 
> When a pointer to a sockaddr_storage structure is first aliased as a
> pointer to a protocol-specific address structure, the effective type
> of the object will be set to the protocol-specific structure.
> 
> This is similar to what happens when malloc(3) is assigned to a
> non-character type.  That's a big hammer, but it does the job.  Maybe
> we would need some looser language?  I CCd GCC, in case they have
> concerns about this wording.
> 
> Cheers,
> Alex
> 
>>
>> I quite like this way of putting it.  It subsumes both what I wrote and 
>> the related potential headache with deciding whether the sa_family_t 
>> field is considered an object or just a range of bytes within a larger 
>> object.
>>
>> zw
> 

For the man pages, I've rewritten it to the following:


$ git diff
diff --git a/man3type/sockaddr.3type b/man3type/sockaddr.3type
index 2fdf56c59..e610aa0f5 100644
--- a/man3type/sockaddr.3type
+++ b/man3type/sockaddr.3type
@@ -117,6 +117,14 @@ .SH HISTORY
 was invented by POSIX.
 See also
 .BR accept (2).
+.PP
+These structures were invented before modern ISO C strict-aliasing rules.
+If aliasing rules are applied strictly,
+these structures would be impossible to use
+without invoking Undefined Behavior (UB).
+POSIX Issue 8 will fix this by requiring that implementations
+make sure that these structures
+can be safely used as they were designed.
 .SH NOTES
 .I socklen_t
 is also defined in


I guess this is simple enough that it should work as documentation.

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