|
Viewing Issue Simple Details
[ Jump to Notes ]
|
[ Issue History ]
[ Print ]
|
|
ID |
Category |
Severity |
Type |
Date Submitted |
Last Update |
|
0001593 |
[Issue 8 drafts] Base Definitions and Headers |
Objection |
Omission |
2022-07-18 00:22 |
2022-07-20 20:34 |
|
|
Reporter |
jscott0 |
View Status |
public |
|
|
Assigned To |
|
|
Priority |
normal |
Resolution |
Open |
|
|
Status |
New |
|
Product Version |
Draft 2 |
|
|
Name |
John Scott |
|
Organization |
unaffiliated |
|
User Reference |
|
|
Section |
sys/un.h |
|
Page Number |
403 |
|
Line Number |
13894 |
|
Final Accepted Text |
|
|
|
Summary |
0001593: specify whether struct sockaddr_un.sun_path can be a flexible array member |
|
Description |
As briefly discussed on austin-group-l, the Standard currently uses flexible array member notation for struct sockaddr_un.sun_path, and this causes some confusion. No implementations are known to use a flexible array member, and furthermore, such an implementation would mean that struct sockaddr_storage would not be suitable for encapsulating a struct sockaddr_un as is intended (unless the size of struct sockaddr_storage were SIZE_MAX, which is absurd and not appropriate for automatic allocation).
If this Desired Action is considered too stringent, an alternative could be to permit sun_path to be a flexible array member. |
|
Desired Action |
Line numbers are from the 1003.1-202x Draft 2, May 2021 document.
At page 403, after line 13894 (the definition of struct sockaddr_un's members), insert the following sentence:
"The sun_path member shall have non-zero size."
At line 13903 in the APPLICATION USAGE, modify the sentence so that it reads "Applications should not assume that sun_path can hold {_POSIX_PATH_MAX} bytes (256)." |
| Tags |
No tags attached. |
|
|
Attached Files |
|
|
|
Relationships 
