This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re:Re: a question about the implementation of errno
Shorter instruction sequence on error path is a good reason.
Thank you, very much!
At 2018-07-04 18:34:59, "Florian Weimer" <fweimer@redhat.com> wrote:
>On 07/04/2018 07:07 AM, lihuiba wrote:
>
>> I noticed recently that errno is implemented as a macro that expands to (*__errno_location()).
>> I wonder why it is implemented as this, and why it is not a thread-local int variable.
>> I suppose thread-local int is faster than function all.
>
>Thread-local errno was added when the library (and the dynamic linker)
>did not support proper TLS variables.
>
>We haven't changed it because it is not clear that it is a win. On some
>platforms, the instruction sequence to call __errno_location and then
>load the value from the returned pointer is actually *shorter* than a
>TLS variable access. Since access to errno happens mostly on error
>paths (where performance isn't a concern, in general), we expect that
>the shorter instruction sequence preferable here.
>
>Thanks,
>Florian