Re: [PATCH] src/ext4_resize.c: set errno to 0 before the strtoull call

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 18/01/2022 08:26, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>   
>>
>> On 18/01/2022 02:27, xuyang2018.jy--- via Libc-alpha wrote:
>>> on 2022/1/18 11:56, Theodore Ts'o wrote:
>>>> On Tue, Jan 18, 2022 at 02:43:26AM +0000, xuyang2018.jy@fujitsu.com wrote:
>>>>>> You're right of course, but out of curiosity, which C library are you
>>>>>> using?
>>>>> I use glibc-2.34.
>>>>
>>>> Hmm, ok.  I'm using glibc 2.31, and in this particular program, errno
>>>> shouldn't have been set by any prior system call.  I'm guessing maybe
>>>> it was something in crt0 which ended up setting errno?
>>> It maybe a glibc bug.
>>> I cc glibc mailing list and see whether they have met this problem.
>>>
>>> @Florian
>>>
>>> Now, I use glibc-2.34 and run the following program[1] but the errno is 
>>> not 0 in the beginning. So is this a known bug on glibc-2.34(Theodore 
>>> doesn't meet this problem on glicb-2.31)?
>>>
>>> [1]https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/tree/src/ext4_resize.c
>>
>> The errno should be only set on a failure, no function shall set errno
>> to 0 (it is a POSIX definition which glibc adheres).  The application
>> need to explicitly set errno to 0 before the function call to check if 
>> an error occurs.
> 
> While this is true, I think errno should still be 0 at the start of the
> program.

I think this is a implementation detail, I am not aware that either C or
POSIX now states it should initialized to any specific value (in fact, 
POSIX at Issue 5 [1] has removed the 'The value of errno is 0 at program 
start-up' on its description).

In any case, we set errno to be an uninitialized TLS variable.  Unless we
have a bug on .tbss initialization I think the issue is somewhere else.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/errno.html