Re: printf(1), sh(1), POSIX.2 and octal escape sequences

[tlaronde%polynum.com@localhost]

Le Wed, Jun 28, 2023 at 01:10:04PM +0000, RVP a écrit :
> On Wed, 28 Jun 2023, tlaronde%polynum.com@localhost wrote:
> 
> > But isn't it incorrect? POSIX 2018 says:
> > 
> > '"\ddd", where ddd is a one, two, or three-digit octal number, shall be
> > written as a byte with the numeric value specified by the octal number.'
> > 
> > since 477 -> 777 are not byte values, shouldn't \777 be interpreted as
> > '\77' octal then the digit 7; \677 -> \67 octal then 7 etc. ?
> > 
> 
> Better to do what the C compiler does: try converting up to 3 digits, and
> if the result of the conversion is > 255, complain.

But you can't: from the syntax given, \777 is a perfectly valid \77
octal sequence followed by the character '7'. Why would the program
error when what is given is, from the syntax, perfectly valid because
the octal sequence is an unfortunate variable length feature---it is
even not specified that the octal sequence will function like the '*' in
regex that is it will try to swallow the maximum of digits that follow
in the range 0-7.

If you try '\778', it will print '?8' and I think it is the correct
behavior from the syntax description.

I would hope that POSIX in a revision specify that this loosy
feature of "variable length octal" is deprecated and discouraged
(unfortunately it can probably not be nuked) and that the new
sequence "\oDDD": backslash, 'o' and exactly three digit from 000
to 377 is the way to unambiguously express an octal number from
now on.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C