Anonymous | Login | 2025-01-16 18:56 UTC |
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 | ||
0001137 | [1003.1(2013)/Issue7+TC1] System Interfaces | Objection | Error | 2017-04-24 23:08 | 2024-06-11 08:54 | ||
Reporter | sebor | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Martin Sebor | ||||||
Organization | |||||||
User Reference | |||||||
Section | fprintf | ||||||
Page Number | 900 | ||||||
Line Number | 30186-30193 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | See Note: 0004145 | ||||||
Summary | 0001137: problems with numbered and unnumbered conversion specifications | ||||||
Description |
On line 30200 POSIX specifies that "Each conversion specification is introduced by the ’%’ character [CX] or by the character sequence "%n$", [CX end] after which the following appear in sequence: ...[optional flags, width, precision, length modifier, and a required conversion specifier]." However, this specification is in apparent contradiction to the text earlier on lines 30186-30187 stating that "The /format/ can contain either numbered argument conversion specifications (that is, "%n$" and "*m$"), or unnumbered argument conversion specifications (that is, % and *), but not both." referring to all of "%n$", "*m$", % and * as conversion specifications. In addition, on line 30224 POSIX further states that "In format strings containing the "%n$" form of a conversion specification, ..." again referring to "%n$" as a form of a conversion specification. I believe the problems are due to the following: First, neither "%" nor "%n$" alone is a complete conversion specification because they are missing the required conversion specifier. Thus the text in the first set of parentheses on lines 30186-30187 isn't entirely correct. Second, neither "*m$" nor "*" is a conversion specification because as shown they are neither introduced by the % character nor followed by a conversion specifier. This makes the text in the second set of parentheses also incorrect. Additionally, on line 30207 POSIX repeats the C requirement that "The field width takes the form of an <asterisk> (’*’), described below, or a decimal integer. and on lines 30213-30215: "The precision takes the form of a <period> (’.’) followed either by an <asterisk> (’*’), described below, or an optional decimal digit string, where a null digit string is treated as zero." effectively excluding the "*m$" form or width and precision, yet seemingly allowing the asterisk and the decimal integer forms in both numbered and unnumbered conversion specifications. But on lines 30223-30225, however, POSIX then goes on to say that "In format strings containing the "%n$" form of a conversion specification, a field width or precision may be indicated by the sequence "*m$" ..." These requirements are both ambiguous and/or contradictory: In format specifications that start with "%n$", is the "*m$" form the only valid for of width and precision, or can they also be specified by a decimal digit string? Also, if precision may be indicated by the sequence "*m$" does it mean that it does not start with the period like the ".*" form does? |
||||||
Desired Action |
1) Replace the sentence on lines 30186-30187 with The /format/ can contain either numbered argument conversion specifications (that is, those introduced by "%n$" and, optionally, containing the "*m$" forms of field width and precision), or unnumbered argument conversion specifications (that is, those introduced by the % character and, optionally containing the * form of field width and precision), but not both. 2) Replace the text on line 30207 with The field width takes the form of an <asterisk> (’*’), [CX] or in conversion specifications introduced by "%n$" the "*m$" string,[CX end] described below, or a decimal integer. 3) Replace the text on lines 30213-30215 with The precision takes the form of a <period> (’.’) followed either by an <asterisk> (’*’), [CX] or in conversion specifications introduced by "%n$" the "*m$" string,[CX end] described below, or an optional decimal digit string, where a null digit string is treated as zero." 4) Replace the text on line 30224 with In format strings containing conversion specifications introduced by "%n$", in addition to being indicated by the decimal digit string, a field width may be indicated by the sequence "*m$" and precision by the sequence ".*m$", where m is a decimal integer ... |
||||||
Tags | tc3-2008 | ||||||
Attached Files | |||||||
|
Issue History | |||
Date Modified | Username | Field | Change |
2017-04-24 23:08 | sebor | New Issue | |
2017-04-24 23:08 | sebor | Status | New => Under Review |
2017-04-24 23:08 | sebor | Assigned To | => ajosey |
2017-04-24 23:08 | sebor | Name | => Martin Sebor |
2017-04-24 23:08 | sebor | Section | => fprintf |
2017-04-24 23:08 | sebor | Page Number | => 982 |
2017-04-24 23:08 | sebor | Line Number | => 30186-30193 |
2018-10-04 15:47 | geoffclare | Project | 1003.1(2008)/Issue 7 => 1003.1(2013)/Issue7+TC1 |
2018-10-04 16:28 | nick | Note Added: 0004145 | |
2018-10-04 16:29 | nick | Interp Status | => --- |
2018-10-04 16:29 | nick | Final Accepted Text | => See Note: 0004145 |
2018-10-04 16:29 | nick | Status | Under Review => Resolved |
2018-10-04 16:29 | nick | Resolution | Open => Accepted As Marked |
2018-10-04 16:30 | nick | Tag Attached: tc3-2008 | |
2018-10-04 16:31 | nick | Page Number | 982 => 900 |
2019-11-05 11:55 | geoffclare | Status | Resolved => Applied |
2024-06-11 08:54 | agadmin | Status | Applied => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |