public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "allachan at au1 dot ibm.com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug stdio/12701] scanf accepts non-matching input
Date: Mon, 26 Nov 2012 08:26:00 -0000	[thread overview]
Message-ID: <bug-12701-131-XyLRFX7h2u@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-12701-131@http.sourceware.org/bugzilla/>

http://sourceware.org/bugzilla/show_bug.cgi?id=12701

paxdiablo <allachan at au1 dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allachan at au1 dot ibm.com

--- Comment #15 from paxdiablo <allachan at au1 dot ibm.com> 2012-11-26 08:26:04 UTC ---
I think this bug report is correct, at least in relation to the '%x/0xz'
sample.

There's a big difference between an input item, which *may* be an initial
subset of a properly scanned directive, and the *properly scanned directive*
itself.

Pushback controls how far you can back up the "input stream pointer" and is the
reason why scanf is usually not used by professionals, who prefer a
fgets/sscanf combo so they can bak up to the start of the line themselves.
However, the pushback is only relevant here in that context. The failure of
'0x' when scanning '%x' will not be able to push back all the way to the '0'
because of this limitation.

The function call sscanf ("a0xz", "%c%x%c") should return 1, not 3.

The controlling part of the standard is the bit dealing with the 'x' directive
itself:

=====
Matches an optionally signed hexadecimal integer, whose format is the same as
expected for the subject sequence of the strtoul function with the value 16 for
the base argument.
=====

The strtoul stuff states:

=====
If the value of base is zero, the expected form of the subject sequence is that
of an integer constant as described in 6.4.4.1, optionally preceded by a plus
or minus sign, but not including an integer suffix. If the value of base is
between 2 and 36 (inclusive), the expected form of the subject sequence is a
sequence of letters and digits representing an integer with the radix specified
by base, optionally preceded by a plus or minus sign, but not including an
integer suffix. The letters from a (or A) through z (or Z) are ascribed the
values 10 through 35; only letters and digits whose ascribed values are less
than that of base are permitted. If the value of base is 16, the characters 0x
or 0X may optionally precede the sequence of letters and digits, following the
sign if present.
=====

The controlling part there would be "a sequence of letters and digits
representing an integer" - you may argue that such a sequence may consist of
zero characters but I don't think anyone in their right mind would suggest that
definition represented an integer. In any case, the '0x' string fails on
strtoul:

    char *x;
    int rc = 42;
    rc = strtoul ("0x", &x, 16);
    printf ("%d [%s]/n", rc, x);
produces:

    0 [0x]
So even though rc is set to 0, the fact that the pointer points to the first
bad character means that the '0x' itself is not a valid hex number.

Putting in '0x5' as the string gives you:

    5 []
so that the first bad character is the end of the string (ie, there WERE no bad
characters).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


  parent reply	other threads:[~2012-11-26  8:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-25 15:13 [Bug libc/12701] New: " bugdal at aerifal dot cx
2011-05-02  1:40 ` [Bug libc/12701] " drepper.fsp at gmail dot com
2011-05-02  2:36 ` bugdal at aerifal dot cx
2011-05-03  0:31 ` drepper.fsp at gmail dot com
2011-05-03  0:40 ` bugdal at aerifal dot cx
2011-05-03  1:14 ` drepper.fsp at gmail dot com
2011-05-03  2:24 ` bugdal at aerifal dot cx
2011-09-25  4:42 ` bugdal at aerifal dot cx
2011-10-29 17:14 ` drepper.fsp at gmail dot com
2011-10-29 21:24 ` bugdal at aerifal dot cx
2011-10-29 21:37 ` drepper.fsp at gmail dot com
2011-10-29 22:04 ` ldv at altlinux dot org
2011-10-30  5:43 ` bugdal at aerifal dot cx
2012-02-21  2:12 ` [Bug stdio/12701] " jsm28 at gcc dot gnu.org
2012-03-17 20:39 ` bugdal at aerifal dot cx
2012-03-18 17:17 ` jsm28 at gcc dot gnu.org
2012-04-18  5:23 ` bugdal at aerifal dot cx
2012-11-26  8:26 ` allachan at au1 dot ibm.com [this message]
2014-06-13 14:54 ` fweimer at redhat dot com
2014-06-27 14:00 ` fweimer at redhat dot com
2021-02-10 19:30 ` bnnf-yellowbot at blurcompany dot com
2021-03-05 15:27 ` bnnf at yahoo dot com
2021-09-15  2:40 ` namboru at jasaseo dot one
2023-07-18 11:44 ` vincent-srcware at vinc17 dot net
2023-07-18 12:01 ` vincent-srcware at vinc17 dot net

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-12701-131-XyLRFX7h2u@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).