Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0000732 [1003.1(2008)/Issue 7] Base Definitions and Headers Objection Enhancement Request 2013-08-11 16:21 2022-09-27 15:28
Reporter shware_systems View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Applied  
Name Mark Ziegast
Organization SHware Systems
User Reference
Section c082.pdf sys/stat.h
Page Number 389
Line Number 13067, 13083-13092
Interp Status ---
Final Accepted Text Note: 0005928
Summary 0000732: Change parameter description of S_IS_XXX macros?
Description The S_ISBLK, etc. macros specify that their parameter shall be from st_mode. However, all the symbolic flag values corresponding to valid inputs are marked XSI.
This implies it is only required of XSI systems that these bits be stored as part of st_mode, as the definition of mode_t in sys/types.h does not require this also.
A basic POSIX system might store type values in another implementation-specific field and not as part of st_mode, in other words, such as st_ftype that helps make its processing of type data more efficient.

As to line 13067 it doesn't have radix specified for Numeric Value header. Octal is implied by the leading zeros, and that is how they are labeled in
other parts, but it could be read as hex also just looking here, leaving hex 8
values as implied place to put an implementation-specific extra permissions bit
and keep it grouped with others. I'd hope no one reads them as decimal. :-)
Desired Action 1) Shade the block 13083-13092 XSI.
or
2) Unshade the block starting at 13054.
or
3) Add language to the definition of mode_t type that it is required to hold as file attributes both file type and file permission bits as defined elsewhere.

or

4) Replace the paragraph at line 13083 with:
[CX] The implementation may define the identifier ST_FTYPE as a macro
that shall expand to the text of the identifier of a field of the stat
structure, as the implementation defines it, such that it may be used as
a ".ST_FTYPE" or "->ST_FTYPE" reference construct to generically represent
which stat field holds the bits representing file type as the parameter m
to the following test macros. [CX]
[XSI] On XSI conformant systems this macro, if defined, shall reference
the st_mode field, e.g.
#define ST_FTYPE st_mode
to be compatible with the type mask values defined above. [XSI]
[CX] A conforming application shall test for the presence of ST_FTYPE
via #if before it uses it with any of the following macros. If it is
not present they shall use a reference to the st_mode field directly
as the parameter m for backwards compatibility purposes. [CX]

The following macros shall be provided to test whether a file is of
the specified type. The macro shall evaluate to a non-zero value if
the test is true; 0 if the test is false. The parameter m supplied to
the macros is the value of the field from a stat structure within
which bit flags representing these file types are stored. [CX] The
ST_FTYPE macro, when defined, may be used to construct references to
this value. It is implementation-defined when XSI conformance is not
claimed whether type mask identifiers are provided. [CX]
======================================

I believe Option 4 is both backwards compatible while still leaving smaller
systems, and much larger, the option of using another field, and provides a
place an implementer can hook onto for supporting some extensions to the file
system and let current apps be forward compatible too. This allows a uchar to
hold type and a short int for attributes, rather than a long int that holds
both, at least for now.

5) Add "(Octal)", or "(In Hex)", to Numeric Value field, or "*" with "* All
values in octal." footnote below table.
Tags tc3-2008
Attached Files

- Relationships
related to 0000834Closed 1003.1(2013)/Issue7+TC1 definition of file mode is too restrictive 

-  Notes
(0005928)
geoffclare (manager)
2022-08-08 16:09

 Change D2.1 line 13473 from:
The implementation may implement message queues, semaphores, or shared memory objects as distinct file types.
to:
The implementation may implement message queues, semaphores, or shared memory objects as distinct file types, in which case these file types need not be encoded in type mode_t.

Change D2.1 line 13482 from:
The implementation may implement typed memory objects as distinct file types, and the following macro shall test whether a file is of the specified type.
to:
The implementation may implement typed memory objects as a distinct file type, in which case this file type need not be encoded in type mode_t. The following macro shall test whether a file is of the specified type.

- Issue History
Date Modified Username Field Change
2013-08-11 16:21 shware_systems New Issue
2013-08-11 16:21 shware_systems Status New => Under Review
2013-08-11 16:21 shware_systems Assigned To => ajosey
2013-08-11 16:21 shware_systems Name => Mark Ziegast
2013-08-11 16:21 shware_systems Organization => SHware Systems
2013-08-11 16:21 shware_systems Section => c082.pdf sys/stat.h
2013-08-11 16:21 shware_systems Page Number => 389
2013-08-11 16:21 shware_systems Line Number => 13067, 13083-13092
2013-08-15 14:43 geoffclare Project 2008-TC1 => 1003.1(2008)/Issue 7
2014-04-24 15:25 eblake Relationship added related to 0000834
2022-08-08 16:09 geoffclare Note Added: 0005928
2022-08-08 16:10 geoffclare Interp Status => ---
2022-08-08 16:10 geoffclare Final Accepted Text => Note: 0005928
2022-08-08 16:10 geoffclare Status Under Review => Resolved
2022-08-08 16:10 geoffclare Resolution Open => Accepted As Marked
2022-08-08 16:10 geoffclare Tag Attached: tc3-2008
2022-09-27 15:28 geoffclare Status Resolved => Applied

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker