This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments (Windows)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]