* 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@xxxxxxxxxxx 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
