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

[Florian Weimer <fweimer@redhat.com>]

* Adhemerval Zanella:

> 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).

It would be nice to stay compatible with that.

> 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.

I suspect it's some additional system call, which is why I requested
strace output.

Thanks,
Florian