Menu ▾ ▴

#1158 Bug in __mingw_snprintf with "%9.0e" format

closed-fixed
nobody
mingw runtime (deprecated use WSL) (77)
2008-06-07
2008-05-11
FX
No

Take the following testcase:

#include <stdio.h>
extern int __mingw_snprintf (char *, size_t, const char *, ...);

int main (void) {
char buf[21];
__mingw_snprintf (buf, 20, "%9.0e\n", 39.);
fputs (buf, stdout);
snprintf (buf, 20, "%9.0e\n", 39.);
fputs (buf, stdout);
return 0;
}

Compiled and run, it gives:

$ gcc u.c -W -Wall && a
3e+01
4e+001

where you can see that __mingw_snprintf() got its rounding wrong (it's the first line of output).

(As an side comment, the Windows snprintf() seems to output more exponent digits than the ones I know in the Unix world, but of course that's a their problem, not mingw's.)

Discussion

  • Danny Smith

    Danny Smith - 2008-05-22

    Logged In: YES
    user_id=11494
    Originator: NO

    I have committed the following patch as obvious. It correct a pasto in
    my original contribution. and fixes this bug. For E format, we want to
    match the output of ecvt. See the comments about MODE in gdtoa.c

    ChangeLog

    2008-05-22 Danny Smith <dannysmith@users.sourceforge.net>

    \[ mingw-Bugs-1961893 \]
\* mingwex/gdtoa/mingw\_snprint.c \(x\_sprintf\): Always set \_\_ldtoa mode
to 2 for E format.

    The patch is at http://www.cygwin.com/ml/cygwin-cvs/2008-q2/msg00107.html

    I have a testcase that compares __mingw_snprintf with MSVC _snprintf for
    this type of thing, but it still needs work to adjust for the e+001 vs
    e+01 diff. This raises the question: Is the two-digit exponent default a
    bug that needs fixing.

     

  • Keith Marshall

    Keith Marshall - 2008-05-22

    Logged In: YES
    user_id=823908
    Originator: NO

    Danny wrote:
    > I have committed the following patch as obvious.

    Thanks, Danny.

    > I have a testcase that compares __mingw_snprintf with MSVC
    > _snprintf for this type of thing, but it still needs work to
    > adjust for the e+001 vs e+01 diff. This raises the question:
    > Is the two-digit exponent default a bug that needs fixing.

    Maybe. Three exponent digits (always) seems to be a Microsoft convention:
    http://msdn.microsoft.com/en-us/library/0fatw238.aspx

    Two digit exponents, for values with exponent magnitude < 100, seems to be the norm for other platforms. Perhaps __mingw_snprintf() should call _get_output_format(), (http://msdn.microsoft.com/en-us/library/571yb472.aspx), and set the exponent width accordingly.

    While on the subject of printf formatting, in general, (and not strictly related to this particular bug report), I don't see any explicit provision within __mingw_snprintf() to handle the `PRI*' format specifiers defined in inttypes.h; I'm assuming that this isn't necessary, since the C preprocessor will already have resolved these to something that __mingw_snprintf() *will* understand, *before* *it* ever gets to see the format string -- I *do* see provision for the Microsoft `I32' and `I64' modifiers, provided we *never* build with `-DNO_MSVC_EXTENSIONS', which is good.

    Given the generally @#!% state of MSVCRT's printf formatting, (I've noted cases where it doesn't even behave as documented; e.g. how do you print out a `long double'? Both "%lf" and "%Lf", as documented at http://msdn.microsoft.com/en-us/library/tcxf1dw6.aspx, seem to print complete garbage on my Win2K box, and the logically necessary equivalents, "%[lL]e" and "%[lL]g", are conspicuously undocumented), we really should consider extending the __mingw_snprintf() concept to the entire printf family of functions, IMHO.

     

  • Danny Smith

    Danny Smith - 2008-06-07
    • status: open --> closed-fixed