On April 27, 2022 1:22 PM, Phillip Wood wrote:
>On 27/04/2022 17:19, Junio C Hamano wrote:
>> Carlo Arenas <carenas@xxxxxxxxx> writes:
>>>> The standard is silent on what happens to error when the value is
>>>> out of range.
>>
>> Actually the standard is is very clear what happens to endptr (no,
>> don't call it "error", that is not the point of the parameter).
> >
>> A pointer to the final string shall be stored in the object
>> pointed to by endptr, provided that endptr is not a null
>> pointer.
>>
>> where "final string" has a precise definition much earlier:
>>
>> First, they decompose the input string into three parts:
>>
>> 1. An initial, possibly empty, sequence of white-space
>> characters (as specified by isspace())
>>
>> 2. A subject sequence interpreted as an integer represented in
>> some radix determined by the value of base
>>
>> 3. A final string of one or more unrecognized characters,
>> including the terminating null byte of the input string.
>>
>> Then they shall attempt to convert the subject sequence to an
>> integer, and return the result.
>>
>> So, leading whitespace is stripped, then "subject sequence" that is
>> the sequence of digits (with optional +/- sign) to be turned into a
>> long is recognised, and what remains is the "final string". endptr is
>> made to point at that "final string", and it does not matter what kind
>> of value the interpretation of "subject sequence" yields.
>
>Oh I think I misunderstood when I read the standard this morning. Just to check I
>do understand now, in the case of overflow entptr points to the final string (i.e. to
>the character following the last digit) even though the "subject sequence" cannot
>be successfully converted?
I can confirm this on multiple 32-bit platforms. With strtol("123456789012345678", &endptr, 10) returns 2147483647 and *endptr == '\0' just beyond the last 8.
