View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001219 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2018-12-12 17:29 | 2024-06-11 08:52 |
Reporter | sebor | Assigned To | ajosey | ||
Priority | normal | Severity | Objection | Type | Error |
Status | Closed | Resolution | Accepted As Marked | ||
Name | Martin Sebor | ||||
Organization | |||||
User Reference | |||||
Section | snprintf | ||||
Page Number | 906 | ||||
Line Number | 30447 | ||||
Interp Status | --- | ||||
Final Accepted Text | See 0001219:0005895. | ||||
Summary | 0001219: snprintf reequirement to fail when n > INT_MAX conflicts with C | ||||
Description | The snprintf description states that: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1-2008 defers to the ISO C standard. and The snprintf() function shall fail if: [CX][EOVERFLOW] The value of n is greater than {INT_MAX}. The requirement conflicts with C. C requires snprintf to succeed regardless of the value of n provided it outputs fewer than INT_MAX bytes. The POSIX requirement prevents implementations from conforming to the C requirement. For example, the following strictly conforming C snippet must not trigger the assertion: char d[1]; int n = snprintf (d, (size_t)INT_MAX + 1, ""); assert (n == 0); while in POSIX the assertion is required to fail. | ||||
Desired Action | Remove the requirement for snprintf to fail when n > INT_MAX. Same for other variants of the function, such as vsnprintf. | ||||
Tags | tc3-2008 |
related to | 0000761 | Closed | 1003.1(2013)/Issue7+TC1 | Requirement of error for snprintf with n>INT_MAX may conflict with ISO C |
|
An alternate solution might be to change C to adopt the same requirement. |
|
I was pointed at the rejected bug 761. Having read through the discussion there, while I think C could and perhaps even should change in this area, I don't entirely agree with the conclusion in comment 0001930 that: The C standard does not specify the behavior when n > INT_MAX, so the current specified behavior does not conflict with the C standard. The C standard does clearly specify the behavior for sprintf calls that produce INT_MAX bytes or less on output, regardless of the value of n: the function returns the size of the output. What C leaves undefined is the behavior of the function when the size of its output is greater than INT_MAX bytes. So to avoid conflicts with C, POSIX can only specify additional requirements when the size of the function output exceeds INT_MAX. Otherwise, requiring calls like snprintf(d, SIZE_MAX, "") to fail does conflict with C. This causes portability problems to code that conforms strictly to the C requirements, and also to compilers like GCC that optimize snprintf calls based on the C requirements (see GCC bug 87096). |
|
Delete lines 30917-30918 in D2.1 (page 904). Change page 990 line 33924 in D2.1 from: The value of n is greater than {INT_MAX}.to: The number of wide characters requested to be written was n or more. |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-12-12 17:29 | sebor | New Issue | |
2018-12-12 17:29 | sebor | Status | New => Under Review |
2018-12-12 17:29 | sebor | Assigned To | => ajosey |
2018-12-12 17:29 | sebor | Name | => Martin Sebor |
2018-12-12 17:29 | sebor | Section | => snprintf |
2018-12-12 17:29 | sebor | Page Number | => 906 |
2018-12-12 17:29 | sebor | Line Number | => 30447 |
2018-12-12 17:48 | sebor | Note Added: 0004182 | |
2018-12-12 20:29 | sebor | Note Added: 0004183 | |
2018-12-12 21:06 | eblake | Relationship added | related to 0000761 |
2022-07-18 15:49 | Don Cragun | Interp Status | => --- |
2022-07-18 15:49 | Don Cragun | Note Added: 0005895 | |
2022-07-18 15:49 | Don Cragun | Status | Under Review => Resolved |
2022-07-18 15:49 | Don Cragun | Resolution | Open => Accepted As Marked |
2022-07-18 15:51 | Don Cragun | Final Accepted Text | => See 0001219:0005895. |
2022-07-18 15:51 | Don Cragun | Tag Attached: tc3-2008 | |
2022-08-05 09:16 | geoffclare | Status | Resolved => Applied |
2024-06-11 08:52 | agadmin | Status | Applied => Closed |