Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001205 [1003.1(2016)/Issue7+TC2] Base Definitions and Headers Objection Clarification Requested 2018-09-02 01:44 2018-09-02 17:01
Reporter kre View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Robert Elz
Organization
User Reference
Section XBD 5
Page Number 124
Line Number 3549
Interp Status ---
Final Accepted Text
Summary 0001205: Incorrect specification of printf %%
Description XBD 5 is mostly used as a method to specify formats used for
output by various utilities and system interfaces (perhaps), and
for that as it is it is fine, as it only needs to adequately
describe the formats that are actually used in those other places,
what would happen if someone did .... is not important.

But it is also used by XCU 4 to specify the operation of the
printf utility, and there it does matter, as users can supply
any random format string.

The issue is that '%' is described as a format conversion specifier
(in addition to its role as the introducer of a conversion specification)

The text starting at line 3439 on page 122 says:

    Each conversion specification is introduced by the
    <percent-sign> character ('%'). After the character '%',
    the following shall appear in sequence:

    flags Zero or more ...
    field width An optional ...
    precision [this one is not stated as optional, that should
                    also be corrected ... but is not the primary subject
                    of this issue]
    conversion specification characters
                   [should be singular, only one is permitted in each
                    conversion ... also not primary subject of this issue]

And then

    The conversion specifiers and their meanings are:
[followed by a big long list, followed, last, by,
at line 3549, on page 124:]
    % Write a '%' character; no argument is converted.

The problem is that this all suggests that %-4.3% is a legal
conversion, and we all know it isn't, the '%' "conversion
specification" can only occur as %%

In XSH 3 (System Interfaces) the page for fprintf (page 914)
at lines 30986-7 which is all (unsurprisingly) very similar,
this is (kind of) handled as ...

    % Print a '%' character; no argument is converted.
      The complete conversion specification shall be %%.

which is kind of adequate, but not the best solution - the
issue is that %% is not a conversion specification at all,
and should not be listed as one. Rather the introductory
text should be something more like

    Each conversion specification is introduced by the
    <percent-sign> character ('%') followed by a character
    that is not another '%'. If consecutive '%' characters
    appear, a single '%' shall be written. Otherwise after
    the character '%', the following shall appear in sequence:

which actually specifies what happens, rather than trying to
fake the second % as a conversion specifier, but a magic one
for which none of the intervening data is permitted.
Desired Action Change lines 3439-3440 (page 122) to:

    Each conversion specification is introduced by the
    <percent-sign> character ('%') followed by a character
    that is not another '%'. If consecutive '%' characters
    appear, a single '%' shall be written. Otherwise after
    the character '%', the following shall appear in sequence:

In line 3447 change the first word of the paragraph ("Gives") to:

    Optionally gives

and in lines 3451-2 (the last sentence of this same paragraph),
change "The precision shall" to

    When given, the precision shall

In line 3454 change "conversion specifier characters" to

    conversion specifier character

Delete line 3549 (page 124).

Of those the first and last changes are those relevant to
the primary issue raised here, the other changes just fix
the more minor irritants noticed while looking.

The primary issue could also be corrected in a similar manner
to that used for fprintf(3) but that is a sub-optimal solution.
If consistency is desired, it would be better to also change
the fprintf specification in a similar way to that proposed here.

% neither is, nor ever has been, a conversion specification.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0004099)
stephane (reporter)
2018-09-02 11:49

FWIW, ksh93 supports %flags% (ksh93 supports quite a large number of extensions when it comes to those flags), though those flags seem to be ignored for %%.

All of %(whatever)%, %02%, %.0$%, %1.2.3% expand to % there.

> Each conversion specification is introduced by the
> <percent-sign> character ('%') followed by a character
> that is not another '%'. If consecutive '%' characters
> appear, a single '%' shall be written. Otherwise after
> the character '%', the following shall appear in sequence:

Maybe "if *two* consecutive '%' characters" as otherwise it may suggest that %%% should result in %.
(0004100)
kre (reporter)
2018-09-02 17:01
edited on: 2018-09-02 17:06

Re note 4099

   Maybe "if *two* consecutive '%' characters"

Yes, agreed (that's what I was thinking...)

And (edited in later) the ksh93 variant would still
be allowed, of course, implementations are free to
add new format conversion characters, and there's
no reason that '%' cannot be one of them - as a
format conversion specifier, it can take whatever
flag or width args it likes, and do whatever it feels
like with them (including nothing).

The only requirement would be that "%%" would always
output a '%' and that is the form that applications
should always use (unless they explicitly want the
non-portable extensions.)

Or more explicitly, printf(1) should not be expected
to support %4% (or anything similar).


- Issue History
Date Modified Username Field Change
2018-09-02 01:44 kre New Issue
2018-09-02 01:44 kre Name => Robert Elz
2018-09-02 01:44 kre Section => XBD 5
2018-09-02 01:44 kre Page Number => 124
2018-09-02 01:44 kre Line Number => 3549
2018-09-02 11:49 stephane Note Added: 0004099
2018-09-02 17:01 kre Note Added: 0004100
2018-09-02 17:06 kre Note Edited: 0004100


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