#1225 Thousands grouping flag not being ignored (with -ansi)


I have gcc-3.4.5 and version 3.15.1 of the mingw runtime. (I have amended stdlib.h, replacing the one occurrence of 'inline' with '__inline__'.)

The demo program:

#include <stdio.h>
#include <stdlib.h>

int main (void)
double d = 5.587555123e-01;
printf("%.10f\n", d);
printf("%'.10f\n", d);
printf("%'.*f\n", 10, d);

return 0;

When compiled with the -ansi switch, that program should output:


Instead, I get:




  • Keith Marshall

    Keith Marshall - 2008-12-28

    Thanks Rob,

    I agree that the output you see is incorrect; in fact, if you substitute any character, which would normally be considered invalid within the context of a format conversion spec, for that thousands grouping flag, then you will see exactly the same incorrect output! This definitely isn't appropriate behaviour. However, I am unconvinced that the output you expect is actually correct, especially in the strictly ANSI conforming context demanded by the `-ansi' option, since there is no thousands grouping flag specified by ANSI.

    On examining the code, I see that the thousands grouping flag should be handled just as any other invalid character; thus, with your sample code, I would expect to see:--


    Do please note that the thousands grouping flag is specified neither in ISO C99 (ANSI), nor in the POSIX base standard; it appears only as a POSIX-XSI extension. The release notes for mingwrt-3.15 are explicit on this: POSIX-XSI extensions are NOT supported. Thus it seems appropriate that the thousands grouping flag should be rejected, as any other invalid character.

  • Keith Marshall

    Keith Marshall - 2008-12-28
    • assigned_to: nobody --> keithmarshall
  • Sisyphus

    Sisyphus - 2008-12-29

    I'm not entirely convinced that the lack of support for the POSIX-XSI extensions *necessarily* implies that the thousands grouping flag should be handled as just another invalid flag. It seems to me that those extensions could perhaps simply be ignored, rather than deemed invalid.
    But I don't have any strong arguments to back that up ... and I'm not the one charged with writing the code :-)
    In short, I'll happily go along with whatever you decide.

    Thanks Keith.


  • Keith Marshall

    Keith Marshall - 2008-12-31

    I've committed a patch, (see below), to address the mishandling of invalid characters; this still leaves the issue of handling POSIX-XSI extensions.

    The problem I have with ignoring the thousands grouping flag is not that it would be difficult to achieve; (in fact, it would be trivially easy). However, that flag really is invalid in any strictly ANSI conforming application, so it seems logical that, especially when `-ansi' is specified, it should be rejected. (Of course, the same would be true of the `%C' and `%S' conversion specs, which are also XSI extensions, and are already fully supported by the current implementation).

    I'm undecided how best to proceed here. Should I disable the support for all POSIX-XSI features completely? Should I leave the two existing *implemented* features as they are? Should I accept the thousands grouping flag, even though I have no supporting implementation, so the only way to deal with it currently would be to ignore it? If I do accept it, how do I handle the one remaining unimplemented XSI feature, the `%n$' style of conversion spec? Implementation of that would be non-trivial, but I can see no logical mechanism for ignoring it.

    In any case, the first priority has got to be to correct the mishandling of characters which are *always* invalid; to address that, I've committed this:

    2008-12-31 Keith Marshall <keithmarshall@users.sourceforge.net>

    Partial fix for MinGW-Bug [2457778]: (Reported by Sisyphus).
    Correct mishandling of invalid characters in printf() format specs.

    * mingwex/stdio/pformat.c (__pformat): Save `fmt' scan position in...
    (backtrack): ...this new automatic variable, at start of each format
    conversion specification substring; use it to backtrack, and print the
    substring literally, if any invalid character is encountered.

    Index: mingwex/stdio/pformat.c

    RCS file: /cvs/mingw/mingw/mingwex/stdio/pformat.c,v
    retrieving revision 1.3
    diff -u -r1.3 pformat.c
    --- mingwex/stdio/pformat.c 18 Oct 2008 14:33:48 -0000 1.3
    +++ mingwex/stdio/pformat.c 31 Dec 2008 15:15:33 -0000
    @@ -1813,6 +1813,11 @@
    __pformat_state_t state = PFORMAT_INIT;
    __pformat_length_t length = PFORMAT_LENGTH_INT;

    + /* Save the current format scan position, so that we can backtrack
    + * in the event of encountering an invalid format specification...
    + */
    + char *backtrack = fmt;
    /* Restart capture for dynamic field width and precision specs...
    int *width_spec = &stream.width;
    @@ -2490,12 +2495,15 @@

    + {
    /* We found a digit out of context, or some other character
    - * with no designated meaning; silently reject it, and any
    - * further characters other than argument length modifiers,
    - * until this format specification is completely resolved.
    + * with no designated meaning; reject this format specification,
    + * backtrack, and emit it as literal text...
    - state = PFORMAT_END;
    + fmt = backtrack;
    + __pformat_putc( '%', &stream );
    + goto format_scan;
    + }

  • Earnie Boyd

    Earnie Boyd - 2012-10-17


    What is the current status of this issue? Was the difference displayed in the 2008-12-31 07:52:46 PST post applied to CVS?


  • Earnie Boyd

    Earnie Boyd - 2012-10-23
    • milestone: --> Aged_issue
    • status: open --> closed-fixed
  • Keith Marshall

    Keith Marshall - 2012-10-23

    I notice you went ahead, and closed it anyway. Just for completeness:

    1) Yes, (the hint is in the message: "I've committed") the patch was committed to CVS.

    2) The original request implied in the subject: "Handle thousands grouping flags" is addressed, by declaring them "invalid", and rejecting the containing format specification accordingly.

    3) The additional XSI feature mentioned, (processing of "%n$" format specifications), remains "unsupported".


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks