DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=F4hYE+IM6im1y7n1
	+YGJm1GOhduqQScEPOSnIgbHjwhDN5DwvvjeXzUL+vDFx1rwLynnXrmrqxqMNS7V
	bDIlurBfExsZS6nBmeuU/JPd67fVppGMG6dlOnQiXElyP4PdZmcWj9tI1p+xfHni
	BpjscIrmc/5uu2YN/V0bmYuhu0Q=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Subject: Re: Integer overflow in functions from scanf() family in MinGW, Cygwin, Borland/Embarcadero C environments (Windows)
To: cygwin AT cygwin DOT com
References: <001101d295e9$65841800$308c4800$@gmail.com>
From: =?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= <HBBroeker AT t-online DOT de>
Message-ID: <24b1c1a0-e40a-5eda-4a6b-f87b4f276c3a@t-online.de>
Date: Mon, 6 Mar 2017 22:34:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <001101d295e9$65841800$308c4800$@gmail.com>
Content-Type: text/plain; charset=iso-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

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