> On Jul 26, 2023, at 5:14 PM, tho...@habets.se wrote:
>
> On Wed, 26 Jul 2023 21:52:32 +0100, Dennis Williamson
> <dennistwilliam...@gmail.com> said:
>> You didn't include all the output. It's treated as a warning rather than an
>> error. That's why an error status isn't set.
>
> Ah indeed, the stderr message with bash builtin has the word
> "warning", whereas the Linux coreutils one does not[1].
>
> Regardless, I do not believe this should be a warning, and instead
> that coreutils is doing the right thing, and bash is not.
POSIX.1-2017 seems to agree [1]. The printf specification states:
If an _argument_ operand cannot be completely converted
into an internal value appropriate to the corresponding
conversion specification, a diagnostic message shall be
written to standard error and the utility shall not exit
with a zero exit status, but shall continue processing any
remaining operands and shall write the value accumulated
at the time the error was detected to standard output.
The nonnormative "Application Usage" section elaborates:
If an argument cannot be parsed correctly for the corresponding
conversion specification, the _printf_ utility is required
to report an error. Thus, overflow and extraneous characters
at the end of an argument being used for a numeric conversion
shall be reported as errors.
A recent austin-group-l discussion seems to concur as well [2].
(Full message forwarded below, if you don't want to follow the URL.)
[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
[2] https://www.mail-archive.com/austin-group-l@opengroup.org/msg11409.html
--
vq
Begin forwarded message:
> From: "Geoff Clare via austin-group-l at The Open Group"
> <austin-grou...@opengroup.org>
> Subject: Re: out-of-bounds numbers in shell utility arguments
> Date: June 26, 2023 at 4:49:45 AM EDT
> To: austin-grou...@opengroup.org
> Resent-From: austin-grou...@opengroup.org
> Resent-To: austin-grou...@opengroup.org
> Reply-To: Geoff Clare <g...@opengroup.org>
>
> Thorsten Glaser wrote, on 24 Jun 2023:
>>
>> what’s the POSIX mode behaviour expected when scripts attempt to
>> use overlong numbers in arguments e.g. to utilities (but possibly
>> anywhere in XSH)?
>>
>> Say a script has on a 64-bit system:
>>
>> test 2 -lt 99999999999999999999
>>
>> I found “1.1.2 Concepts Derived from the ISO C Standard” in XSH
>> Introduction, but that just says it should be signed long.
>
> XCU 1.1.2 relates to utilities that "perform complex data manipulation
> using their own procedure and arithmetic languages". So it applies to
> shell arithmetic expansion, but isn't really relevant to simple
> argument parsing by a utility. For that, the relevant text is in XBD
> 12.1 Utility Argument Syntax, item 6. This specifies ranges that must
> be "syntactically recognized as numeric values" and then says "Ranges
> greater than those listed here are allowed."
>
> So the allowed behaviours are that either the utility syntactically
> recognises the argument as a numeric value or it doesn't.
>
> If it doesn't, then it must report this as a syntax error.
> If it does, then its behaviour must be as described by the standard
> for the value that was recognised.
>
>> So, is it:
>>
>> • application error (the script writer is at fault, and the shell
>> can do what it wants but should be consistent)
>>
>> • unspecified behaviour (the shell can do as it wants but should
>> be consistent); I really hope not C-level UB
>>
>> • the utility or shell must detect this, while parsing the argument
>> as number, erroring out
>>
>> I’d hope for one of the first two because having wraparound semantics
>> is one of the guarantees for script writers I have in mksh for shell
>> arithmetics (not yet explicitly in the test(1) builtin).
>
> It's somewhere between the second and third. It's unspecified whether
> the utility will report an error, but if it doesn't then it has to
> handle the value correctly, i.e. test 2 -lt 99999999999999999999 must
> exit with status 0 or status >1; it must not exit with status 1.
>
> --
> Geoff Clare <g.cl...@opengroup.org>
> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
>
