snprintf and __USE_MINGW_ANSI_STDIO

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

snprintf and __USE_MINGW_ANSI_STDIO

Burkhardt, Glenn B        UTAS
It looks like "snprintf" and friends don't have the same definitions to use the ANSI stdio functions like printf, fprintf, and sprintf do.  The result is that if __USE_MINGW_ANSI_STDIO is defined, and -Wall is used, there are compile time warnings if specifications like "%lld" are used.  The function actually works correctly with "%lld".  

Is this a bug, or am I missing something?


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: snprintf and __USE_MINGW_ANSI_STDIO

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/11/16 13:50, Burkhardt, Glenn B        UTAS wrote:
> It looks like "snprintf" and friends don't have the same
> definitions to use the ANSI stdio functions like printf, fprintf,
> and sprintf do. The result is that if __USE_MINGW_ANSI_STDIO is
> defined, and -Wall is used, there are compile time warnings if
> specifications like "%lld" are used.

This is nothing whatsoever to do with __USE_MINGW_ANSI_STDIO, (which you
really SHOULDN'T define yourself, BTW; use appropriate _POSIX_C_SOURCE,
or _XOPEN_SOURCE definitions instead).  This is just evidence of the
inherent dumbness of GCC's printf format warnings.

> The function actually works correctly with "%lld". Is this a bug,
> or am I missing something?

If the function works correctly, it's hardly a bug, is it?  GCC's printf
format warning feature is unlikely to deliver sane diagnostics, while it
assumes that only MSVC semantics are applicable.  (FWIW, the second most
prevalent diagnostic emitted during a build of GCC itself, is a swathe
of bogus warnings about MSVC format specifiers).

If they bother you, disable the -Wformat (-Wno-format) messages, (or,
maybe better, use the format specifier macros from <inttypes.h>).

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYLHszAAoJEMCtNsY0flo/ikkP/RQEvIFCaQdSg0Ne5sxuufSu
Ar41AjaO4BjlKlvVrR3Wu7Whox8QSZ6aZ7EpBSRwKQXMgdFuuLpD+oH1N/lo25Fs
bzZVDcHnPOGs+gtjD8VecfJrCc2W0CztuUZRaeVeyC8IZCcKU/8YsgQ52THOfdAG
GQzKTHEmk1SsFRI7mpWiQa51ngMXK/P2zoTjLgreRk+3xv3XVBi5K1H9n453pnVL
i9L6w7QD2HSbMvqAqqkLSHbsSGXL3grEjY8ZgOEwHyoj++T1nJwR9F1eT3OSELMJ
1Hz7+nRUBPY0IKW5LGzi+SsGnAUC5MbHTS0PD1RXORkxkap7pyJeQVXpdmSvgcBY
NDrpSlja9d47whnOQhXeWT5pT3uqmjm53ZM1SNquCP28ky/+1ghhvleSP3dP56xE
NnQTTozQUCr/E2LDpOQ5NwrFfqCmHLYPAwqicre92063CqRktel2KMEAKOAvSmtk
N4n4Wuoccq2zSC6A6yuEFv2sGZ1dIGY1OQBKOOUqQfX20JW2LToJbQ1GfFAIfCyp
ZRiSwbBdZlz84lKHawXz2noyB3DwZYOcVP0w6uDgmFj4dAW3tlPyo+OL5kSESYxt
KFBwipiMx+MrSbBH5crAezopoHkgbXt0xcggjysm/gtOOR1HGJturyw66JXvbgfL
YhvOQGYg3ITnukk2iI/f
=QE71
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: snprintf and __USE_MINGW_ANSI_STDIO

Eli Zaretskii
> From: Keith Marshall <[hidden email]>
> Date: Wed, 16 Nov 2016 15:28:52 +0000
>
> On 16/11/16 13:50, Burkhardt, Glenn B        UTAS wrote:
> > It looks like "snprintf" and friends don't have the same
> > definitions to use the ANSI stdio functions like printf, fprintf,
> > and sprintf do. The result is that if __USE_MINGW_ANSI_STDIO is
> > defined, and -Wall is used, there are compile time warnings if
> > specifications like "%lld" are used.
>
> This is nothing whatsoever to do with __USE_MINGW_ANSI_STDIO, (which you
> really SHOULDN'T define yourself, BTW; use appropriate _POSIX_C_SOURCE,
> or _XOPEN_SOURCE definitions instead).  This is just evidence of the
> inherent dumbness of GCC's printf format warnings.

I'm not sure it's GCC dumbness: it could be that the code in question
has some prototype that uses __attribute__ ((format (printf, ...))).

The solution is to use __attribute__ ((format (ms_printf, ...)))
instead; see the GCC manual for the details.  (Perhaps MinGW headers
should do that themselves?)

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: snprintf and __USE_MINGW_ANSI_STDIO

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/11/16 16:00, Eli Zaretskii wrote:

>> From: Keith Marshall This is nothing whatsoever to do with
>> __USE_MINGW_ANSI_STDIO, (which you really SHOULDN'T define
>> yourself, BTW; use appropriate _POSIX_C_SOURCE, or _XOPEN_SOURCE
>> definitions instead).  This is just evidence of the inherent
>> dumbness of GCC's printf format warnings.
>
> I'm not sure it's GCC dumbness: it could be that the code in
> question has some prototype that uses __attribute__ ((format
> (printf, ...))).
>
> The solution is to use __attribute__ ((format (ms_printf, ...)))
> instead; see the GCC manual for the details.  (Perhaps MinGW
> headers should do that themselves?)

No.  IMO, it is GCC dumbness.  See, "ms_printf" is the default for the
MinGW build of GCC; the "dumbness" arises because GCC's alternatives,
"ms_printf" vs. "printf" (or "gnu_printf") are mutually exclusive, but
our alternative to the MSVCRT.DLL printf formatting is a hybrid of the
two; (IOW, you may avoid the warnings by using MSVCRT.DLL specifiers,
as the <inttypes.h> macros do; ISO-C alternatives are equally accepted,
but GCC will complain that they are unrecognised).

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYLIkOAAoJEMCtNsY0flo/fZsP/2Ero2JP3FVnQa1NfoFCr7Ad
FlfNfcME5zzYuPdq4X+L7RgSIoa/mmt+S5M7O0DzbGR0KE1KkdWT+EmXRaMhnfRu
1Un4YY4D2zXMtREbFsZIzBIhCXLFN9kcKkFt2zfnYdYTH6XCstktuYfYv23tf0kw
ZnD4jac+1bGP8FNfHPrQgm/bFPOhEOBNKu49Eb8jSZurdkvlR1k9SGF9XFKLXwXn
gshsa6fRRc+01ymSGlVjQr5gglkEu5ryXh2syOWTP38em64z3OXPuI2PWHjwDrGa
7xVR+eNBxNgHazF3YYI+Ny0rM/sPm0M3Fy7jENggYWd3nUMPXFVupyFy6OXOF7kA
GGXkOmoZZiXqjZxbKsaHYZXyDgN2K6uxTTxC25EyfeSUP/JPGB90d0u+2W23weoh
pGKFyc/+hMVKyIUp3PqskBQu+hcbIoLr7ihFBIXWXaP1YwzMWf6MwbXGjXnab3fU
VGpLfl7NuC9Yx0YVtmq21ObLJ1NdwGyXMsLTKyZ9JALgDYBvzr6UrARc2I+E7zdW
u4sZ/aLEOALSHScLjfJ64eDk1eTWgDuA+rRb+PESX85tZW9W2Jz01dtXk4kvJla1
QrjpkO3BhDnoeXJTzz0HHORzllP+kReWYVTnv+RPEDb0/A6bz7TfF+4EogerosMf
++1/1JF9R2dzJAGlW+pC
=2Spc
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: snprintf and __USE_MINGW_ANSI_STDIO

Burkhardt, Glenn B        UTAS
In reply to this post by Burkhardt, Glenn B UTAS
On 16/11/16 13:50, Burkhardt, Glenn B        UTAS wrote:
> It looks like "snprintf" and friends don't have the same definitions
> to use the ANSI stdio functions like printf, fprintf, and sprintf do.
> The result is that if __USE_MINGW_ANSI_STDIO is defined, and -Wall is
> used, there are compile time warnings if specifications like "%lld"
> are used.

On Wed 11/16/2016 11:28, Keith Marshall wrote:
> This is nothing whatsoever to do with __USE_MINGW_ANSI_STDIO, (which you really SHOULDN'T define yourself, BTW; use appropriate
> _POSIX_C_SOURCE, or _XOPEN_SOURCE definitions instead).  This is just evidence of the inherent dumbness of GCC's printf format warnings.

I have to disagree with you.  The problem is the omission of the correct definition for "snprintf" with __USE_MINGW_ANSI_STDIO defined.  It works for "printf", and "sprintf".  Look at stdio.h - the static definition for "sprintf" is there to use __mingw_vsprintf(), but is missing for "snprintf".

This small program:

#define __USE_MINGW_ANSI_STDIO 1
#include <stdio.h>

int main()
{
    long long x = 0x100000000L;
    char buff[128];

    printf("%lld\n", x);
    sprintf(buff, "%lld\n", x);
    printf("%s", buff);
    snprintf(buff, sizeof(buff), "%lld\n", x);
    printf("%s", buff);

    return 0;
}

gives these warnings:
$ gcc -g -Wall tt.c -o tt
tt.c: In function 'main':
tt.c:12:5: warning: unknown conversion type character 'l' in format [-Wformat]
tt.c:12:5: warning: too many arguments for format [-Wformat-extra-args]

But the "snprintf" call works properly.  The output is:
4294967296
4294967296
4294967296

> > The function actually works correctly with "%lld". Is this a bug, or
> > am I missing something?

> If the function works correctly, it's hardly a bug, is it?  GCC's printf format warning feature is unlikely to deliver sane diagnostics, while it assumes that
> only MSVC semantics are applicable.  (FWIW, the second most prevalent diagnostic emitted during a build of GCC itself, is a swathe of bogus
> warnings about MSVC format specifiers).

Call me fastidious, but I find that compiler warnings often alert me to real errors in the code.  False positives waste my time.

> If they bother you, disable the -Wformat (-Wno-format) messages, (or, maybe better, use the format specifier macros from <inttypes.h>).

BTW, the correct format specifiers for int64_t, viz, PRId64, are wrong when using __USE_MINGW_ANSI_STDIO.  That's another bug.

Also, for what it's worth, this all works properly with the headers from the MinGW-w64 fork of the MinGW code, and on every Linux system I use.   :-)


------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: snprintf and __USE_MINGW_ANSI_STDIO

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/11/16 18:28, Burkhardt, Glenn B        UTAS wrote:

> On 16/11/16 13:50, Burkhardt, Glenn B        UTAS wrote:
>> It looks like "snprintf" and friends don't have the same
>> definitions to use the ANSI stdio functions like printf, fprintf,
>> and sprintf do. The result is that if __USE_MINGW_ANSI_STDIO is
>> defined, and -Wall is used, there are compile time warnings if
>> specifications like "%lld" are used.
>
> On Wed 11/16/2016 11:28, Keith Marshall wrote:
>> This is nothing whatsoever to do with __USE_MINGW_ANSI_STDIO,
>> (which you really SHOULDN'T define yourself, BTW; use appropriate
>>  _POSIX_C_SOURCE, or _XOPEN_SOURCE definitions instead).  This
>> is just evidence of the inherent dumbness of GCC's printf format
>> warnings.
>
> I have to disagree with you.  The problem is the omission of the
> correct definition for "snprintf" with __USE_MINGW_ANSI_STDIO
> defined.

No, it isn't ... at least not entirely.

> It works for "printf", and "sprintf".

Again, no it doesn't ... if you compile your code as C++, you will see
those -Wformat messages, regardless.

> This small program:
>
> #define __USE_MINGW_ANSI_STDIO 1

That's just asking for trouble; it may work (fortuitously) today, but
I could change the semantics associated with the interpretation of this
INTERNALLY RESERVED macro tomorrow, and break your code, and I will not
feel the slightest remorse over your problem.  Use _POSIX_C_SOURCE, or
_XOPEN_SOURCE, (or even _GNU_SOURCE), to make your usage safe.

> #include <stdio.h>
>
> int main() { long long x = 0x100000000L; char buff[128];
>
> printf("%lld\n", x); sprintf(buff, "%lld\n", x); printf("%s",
> buff); snprintf(buff, sizeof(buff), "%lld\n", x); printf("%s",
> buff);
>
> return 0; }
>
> gives these warnings: $ gcc -g -Wall tt.c -o tt tt.c: In function
> 'main': tt.c:12:5: warning: unknown conversion type character 'l'
> in format [-Wformat] tt.c:12:5: warning: too many arguments for
> format [-Wformat-extra-args]

And I get the same diagnostics, repeated for each of the printf() and
sprintf() calls too, if I add -xc++ to compile your simple program as
if it were C++ code.

> But the "snprintf" call works properly.  The output is: 4294967296
> 4294967296 4294967296

Of course it does; the implementation correctly interprets both the "ll"
and the "I64" format modifiers, regardless of any bogus assumptions made
by GCC/G++ at compile time.

> Call me fastidious, but I find that compiler warnings often alert
> me to real errors in the code.  False positives waste my time.

Right; and -Wformat is a known source of false positives.

> BTW, the correct format specifiers for int64_t, viz, PRId64, are
> wrong when using __USE_MINGW_ANSI_STDIO.  That's another bug.

No, it is not.  The implementation understands "I64d", (which is what
PRId64 represents), to mean IDENTICALLY the same as "lld"; this is
correct BY DESIGN, so it certainly is not a bug.  In fact, if you use
"%" PRId64 in your example program, the bogus -Wformat messages go away;
(of course, you do need to define __STDC_FORMAT_MACROS, before including
<inttypes.h>, to make the C++ case work).

> Also, for what it's worth, this all works properly with the
> headers from the MinGW-w64 fork of the MinGW code, and on every
> Linux system I use.

Whatever behaviour you observe on Linux isn't remotely germane to any
discussion of MinGW behaviour; OTOH, if you believe that the mingw-w64
folks have a solution, which works equally well for BOTH C and C++, and
you can offer me a patch, I will certainly consider it.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJYLX6OAAoJEMCtNsY0flo/gIMP/im6S9JFgRAkwuZiMMGJkdWh
vS0OoK6AJ2JHJOWhlhKB4RzRW9+x8LL0abga4AMG3LDQRZPv4achFJbeiRO7R3HC
RTLpvtMHpH+4+JPhNxOgPmqA7pZnz8DfcnA64WMdLsiQx35dYsFmRRRfP8pRsich
Od4uoV4sYLX1UeE1egCq/UdsWaHrPCXs4N4XGTswJlJkOPWTBBUfHGg9HAXnNGzZ
3j4NEFbS+8RcCieCKAIT78LfR3ByfuQb513XYTnfpkxPEPja2H+b0yYMEeid6BEu
canMUOpFBPUbYLQRP/CoozUveWc9kFO80AWVLM6gJJXPESpqcg53X9uxCXLFLnkV
oHcLGauma4uhwe8mU/U1tbI9jTr/Ff+UaJYgZx0A12H9gcga64Yu9YmcVqFIDR56
W3amqCKAgvvNcMZB68Scbe2sIHXLE0uwuUMiDo9WlV6upd0ce2F/oSpm5eiLakSx
mnnpdH9Qa6iveSPRPo9U50E4B1cBprmPts7aJmgqmFlk62k6oZa4xSW6MMxuaGBW
hR3zWmm+RUV4Li7E1FiXJvSr/l91Q8qZbwJILY0JWUpzNA6stxQ4N0RjVUKYd5Cd
BydjMgn2mqdu3njPLp8/isTbi3qlbihQ+d2LDA6Tfg9+05TniR07aiNikDRLEGhb
mQOP+rO9r7pgrVIpJGTS
=THaI
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Loading...