A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1641 
====================================================================== 
Reported By:                bastien
Assigned To:                
====================================================================== 
Project:                    1003.1(2016/18)/Issue7+TC2
Issue ID:                   1641
Category:                   System Interfaces
Type:                       Clarification Requested
Severity:                   Editorial
Priority:                   normal
Status:                     Interpretation Required
Name:                       Bastien Roucaries 
Organization:               debian 
User Reference:              
Section:                    sys/socket.h 
Page Number:                Application usage 
Line Number:                sockaddr_storage 
Interp Status:              Pending 
Final Accepted Text:        see
https://austingroupbugs.net/view.php?id=1641#c6255 
====================================================================== 
Date Submitted:             2023-03-18 07:52 UTC
Last Modified:              2023-04-06 19:24 UTC
====================================================================== 
Summary:                    sockaddr_storage is not alias safe
====================================================================== 

---------------------------------------------------------------------- 
 (0006257) eblake (manager) - 2023-04-06 19:24
 https://austingroupbugs.net/view.php?id=1641#c6257 
---------------------------------------------------------------------- 
[Copying a message from Zack Weinberg on
https://sourceware.org/pipermail/libc-alpha/2023-April/147046.html]

If I could suggest an additional change, the focus on aliasing
_diagnostics_ rather misses the point IMHO.  We don't just want the
compiler to _not complain_ about accesses to sa_family_t, we want it to
treat the accesses as _legitimate_.  So, instead of

# Additionally, the structures shall be defined in such a way that
# these casts do not cause the compiler to produce diagnostics about
# aliasing issues in accessing the sa_family_t member of these
# structures when compiling conforming application (xref to XBD section
# 2.2) source files.

may I suggest wording along the lines of

# 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, despite the
# more restrictive rules listed in ISO C section 6.5p7. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2023-03-18 07:52 bastien        New Issue                                    
2023-03-18 07:52 bastien        Name                      => Bastien Roucaries
2023-03-18 07:52 bastien        Organization              => debian          
2023-03-18 07:52 bastien        Section                   => sys/socket.h    
2023-03-18 07:52 bastien        Page Number               => Application usage
2023-03-18 07:52 bastien        Line Number               => sockaddr_storage
2023-03-18 07:53 bastien        Note Added: 0006207                          
2023-03-18 07:53 bastien        Issue Monitored: bastien                     
2023-03-20 13:20 wlerch         Note Added: 0006208                          
2023-03-20 13:38 bastien        Note Added: 0006209                          
2023-03-20 23:06 steffen        Note Added: 0006211                          
2023-03-21 12:01 hvd            Note Added: 0006212                          
2023-03-21 23:09 sam_james      Note Added: 0006215                          
2023-03-21 23:33 steffen        Note Added: 0006216                          
2023-03-22 09:42 bastien        Note Added: 0006217                          
2023-03-22 21:56 steffen        Note Added: 0006227                          
2023-03-30 15:20 eblake         Note Added: 0006238                          
2023-03-30 15:22 eblake         Interp Status             => ---             
2023-03-30 15:22 eblake         Final Accepted Text       => see
https://austingroupbugs.net/view.php?id=1641#c6238
2023-03-30 15:22 eblake         Status                   New => Resolved     
2023-03-30 15:22 eblake         Resolution               Open => Accepted As
Marked
2023-03-30 15:22 eblake         Tag Attached: issue8                         
2023-04-03 16:31 eblake         Status                   Resolved => Under
Review
2023-04-03 16:31 eblake         Resolution               Accepted As Marked =>
Reopened
2023-04-03 16:36 eblake         Note Added: 0006249                          
2023-04-03 22:42 steffen        Note Added: 0006253                          
2023-04-03 22:44 steffen        Note Added: 0006254                          
2023-04-06 15:42 eblake         Note Added: 0006255                          
2023-04-06 15:43 eblake         Interp Status            --- => Pending      
2023-04-06 15:43 eblake         Final Accepted Text      see
https://austingroupbugs.net/view.php?id=1641#c6238 => see
https://austingroupbugs.net/view.php?id=1641#c6255
2023-04-06 15:43 eblake         Status                   Under Review =>
Interpretation Required
2023-04-06 15:43 eblake         Resolution               Reopened => Accepted As
Marked
2023-04-06 15:44 eblake         Tag Attached: tc3-2008                       
2023-04-06 15:44 eblake         Tag Detached: issue8                         
2023-04-06 19:24 eblake         Note Added: 0006257                          
======================================================================


  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to