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