bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7574: [PATCH]: echo, printf, stat: Allow only up to 8 bit octal inpu


From: Eric Blake
Subject: bug#7574: [PATCH]: echo, printf, stat: Allow only up to 8 bit octal input for backslash-escaped chars
Date: Mon, 06 Dec 2010 11:32:35 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.6

On 12/06/2010 09:34 AM, Ondrej Vasik wrote:
> Hi,
> as reported in RHBZ#660033
> ( https://bugzilla.redhat.com/show_bug.cgi?id=660033 ), echo, printf and
> stat allows 3 octal digits without limitation to 8-bit.

First, let's look at POSIX, which has slightly different wording in its
requirements for 'echo' and 'printf' (for stat, we can do whatever we want).

echo: Support is only required for an "8-bit value" \0num, that is, a
leading 0 is required, and num may be 0-3 (but no more) digits.  \1 is
implementation-defined (we happen to define it as shorthand for \01).

printf: In the format argument, support is required for \ddd, where ddd
may be 1-3 (but no more) digits; no leading 0 required, and leading zero
counts against your 3 digits.  When matching up to the %b escape in the
format argument, support is required for \0ddd, where ddd may be 0-3
(but no more digits), with the same rules about leading 0 as in echo.
Both cases mention "converted to a byte with the numeric value", and
POSIX requires bytes to be 8-bit values.

Given the similarity between printf %b and echo, I think we can safely
assume that "byte with the numeric value" of printf should be treated as
"8-bit value" of echo.  Therefore, in either case, I agree with your
assessment that \0610 should necessarily be treated as '\061' followed
by the character '0', since the octal value 0610 is not 8-bit, and that
printf \300 should be treated as '\30' followed by '0'.

> Because of the unsigned char overflow, I prefer the 8-bit limit - and I
> did so in attached patch. As I don't expect this will be noticed by
> anyone (probably most of users already limit these octals to 8-bit
> independently), I didn't added NEWS entry.

It still deserves a NEWS entry, since this is a bug fix.

> Test testing printf '\0610'
> output is added. Previously it was interpreted as 392 and this was
> passed to putchar(), after the patch it is interpreted as '\061' + '0'
> => 10 .

Sounds correct to me, although I haven't closely reviewed the patch yet.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]