This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments (Windows)
- From: Hans-Bernhard Bröker <HBBroeker at t-online dot de>
- To: cygwin at cygwin dot com
- Date: Mon, 6 Mar 2017 22:34:42 +0100
- Subject: Re: Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments (Windows)
- Authentication-results: sourceware.org; auth=none
- References: <001101d295e9$65841800$308c4800$@gmail.com>
Am 05.03.2017 um 20:48 schrieb Lukas' Home Page:
Good morning,
I find out a strange and bad beaviour in functions from scanf() family when
reading one-byte int variable in MinGW, Cygwin and Borland/Embarcadero C
environments
Actually, I'm pretty sure this only happens on MinGW. Neither the
problem nor your explanation applies to Cygwin, and I find it very hard
to believe that your explanation could apply to Borland/Embarcadero C.
This bug is
corelated with MSVCRT library which isn't written in C99 standard (it's
written in C89 i think).
Close, but not quite correct. The bug is in MinGW, and the nature of
the bug is that they still use MSVCRT, even if a C99 build was asked
for. As long as MingW puts uses the msvcrt.dll versions of the *scanf()
functions (instead of one of its later replacements, e.g. mscvr120.dll,
or rolling their own), they simply cannot implement C99.
But that's not for Cygwin, but rather for MinGW to address. So please
take this issue to them.
This works, because scanf() in old MSVCRT library doesn't know "h" format
specifier.
That claim is wrong on two counts. That "h" is not a format specifier,
but rather a length modifier here. And MSVCRT does know "h". What it
doesn't recognize (because of its age, and Microsoft's long-time refusal
to act on the C99 standard) is the doubled-up "hh" modifier.
The C99 specification says on 361 page:
To a considerable extent, what the C99 specification says on this matter
is irrelevant, because MSVCRT never claimed to implement C99. That
doesn't change this argument though, because the same wording was in
C90, too:
"If a
conversion specification is invalid, the behavior is undefined." - but it is
WRONG, because the behaviour SHOULD BE DEFINED AS OMITING THE WHOLE
UNSUPPORTED PART OF FORMAT
It's not nearly as wrong as to justify you SCREAMING about it. Nor is
it even up to you to decide what is wrong in an international standard
document. Just because you would prefer different wording doesn't make
it wrong.
#include <stdio.h>
#include <stdbool.h>
typedef volatile unsigned char uint8_t;
int main()
{
bool allowAccess = false; // allowAccess should be always FALSE
uint8_t userNumber;
char format[] = "%hhu";
char buffer[] = "257\n";
sscanf(buffer, format, &userNumber);
This code causes undefined behaviour even in a fully correct C99
implementation, because it tries to convert the value 257 into an 8-bit
object. (C99 7.19.6.2p10, last sentence). That renders it unfit to
demonstrate anything.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple