A NOTE has been added to this issue. 
====================================================================== 
http://austingroupbugs.net/view.php?id=1274 
====================================================================== 
Reported By:                dannyniu
Assigned To:                
====================================================================== 
Project:                    1003.1(2016)/Issue7+TC2
Issue ID:                   1274
Category:                   Base Definitions and Headers
Type:                       Omission
Severity:                   Editorial
Priority:                   normal
Status:                     New
Name:                       DannyNiu/NJF 
Organization:               Individual 
User Reference:              
Section:                    <sys/types.h> header 
Page Number:                402-405 
Line Number:                13652-13746 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2019-07-28 10:42 UTC
Last Modified:              2019-08-27 16:26 UTC
====================================================================== 
Summary:                    pid_t must fit in an int for definition of fcntl to
be consistent.
====================================================================== 

---------------------------------------------------------------------- 
 (0004542) eblake (manager) - 2019-08-27 16:26
 http://austingroupbugs.net/view.php?id=1274#c4542 
---------------------------------------------------------------------- 
The standard has historically NOT mandated a particular struct layout; it
is intentional that implementations are allowed to provide additional
fields and/or padding (as long as the presence of those additional fields
do not change the behavior of a strictly-conforming application that only
uses the standard-mandated fields).  For example, 'struct stat' does NOT
bother to use uint16_t or int32_t or any other specifically-sized types;
its use of 'int' is sufficient for portability (that is, the standard does
NOT let you assume a particular layout of struct stat, but portable code
does not care about the layout in the first place).

I think that the standard mandating 'int type;' as one of the members of
the f_owner_ex structure is sufficient; it is then up to the libc
implementation to ensure that the struct that the user space application
populates based on what <fcntl.h> declares can then be translated into the
appropriate semantics when making a syscall into the kernel (in fact, an
implementation that puts the pid_t pid field prior to the int type field
would be just as compliant).  Thus, whether the glibc implementation uses
'int type;' or 'enum XYZ type;' with a required compilation environment
that treats enum XYZ indistinguishable from int, shouldn't really matter to
the standard (it becomes a quality-of-implementation issue for glibc if
they decide to use a more specific enum type instead of 'int', but as long
as a compliant application cannot detect the difference, it shouldn't
matter). 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2019-07-28 10:42 dannyniu       New Issue                                    
2019-07-28 10:42 dannyniu       Name                      => DannyNiu/NJF    
2019-07-28 10:42 dannyniu       Organization              => Individual      
2019-07-28 10:42 dannyniu       Section                   => <sys/types.h>
header
2019-07-28 10:42 dannyniu       Page Number               => 402-405         
2019-07-28 10:42 dannyniu       Line Number               => 13652-13746     
2019-07-28 13:49 jilles         Note Added: 0004496                          
2019-07-29 00:52 shware_systems Note Added: 0004497                          
2019-07-29 09:08 geoffclare     Note Added: 0004498                          
2019-08-15 16:37 eblake         Note Added: 0004524                          
2019-08-15 16:52 shware_systems Note Added: 0004525                          
2019-08-15 16:58 eblake         Note Added: 0004526                          
2019-08-15 19:03 shware_systems Note Added: 0004527                          
2019-08-15 19:32 eblake         Note Added: 0004528                          
2019-08-15 19:33 eblake         Note Edited: 0004528                         
2019-08-23 16:15 geoffclare     Note Added: 0004536                          
2019-08-24 19:56 shware_systems Note Added: 0004538                          
2019-08-24 19:58 shware_systems Note Edited: 0004538                         
2019-08-27 15:31 geoffclare     Note Added: 0004540                          
2019-08-27 16:16 shware_systems Note Added: 0004541                          
2019-08-27 16:17 shware_systems Note Edited: 0004541                         
2019-08-27 16:26 eblake         Note Added: 0004542                          
======================================================================


Reply via email to