Date: Sun, 28 Aug 2016 15:28:02 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Andrey Chernov <ache@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys Message-ID: <20160828144742.G1008@besplex.bde.org> In-Reply-To: <70b3b052-4c29-c332-14bf-e50847636a8a@freebsd.org> References: <201608272303.u7RN3N0D078505@repo.freebsd.org> <9bcf10db-de3f-33ce-e418-03ce3283ac90@freebsd.org> <20160828005637.GG83214@kib.kiev.ua> <59ac1812-7c77-b677-51c4-dcadc6b2be7f@freebsd.org> <20160828011501.GH83214@kib.kiev.ua> <80ad9e03-74bc-8c99-666f-787772bef2b9@freebsd.org> <20160828015210.GI83214@kib.kiev.ua> <70b3b052-4c29-c332-14bf-e50847636a8a@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 Aug 2016, Andrey Chernov wrote:
> On 28.08.2016 4:52, Konstantin Belousov wrote:
>>>>> POSIX: "For each thread of a process, the value of errno shall not be
>>>>> affected by function calls or assignments to errno by other threads."
>>>> And ? What should the citation add new to the substance
>>>> of the code change ?
>>>
>>> This is for your comment "On both i386 and amd64, the errno symbol was
>>> directly referenced, which only works correctly in single-threaded
>>> process."
>> I still do not understand what you want to say there. Errno as the
>> symbol existing in the symbol table of libc, gives 'POSIX errno' value
>> for the main thread. Preprocessor definition converts C language
>> accesses to errno into some indirections which result in accesses to
>> per-thread errno location. The bug in x86 asm code was due to direct
>> usage of errno.
>
> This particular quote is not describing a problem, it supports your change.
>
>> I know that POSIX requires that POSIX-defined functions did not modified
>> errno except on error,
>
> POSIX don't say it. You may modify errno to any value besides 0 while
> returning success from the function excepting only those functions where
> POSIX directly states they can't modify errno. I.e. only 0 is disallowed
> in all cases.
POSIX seems to be very deficient in stating which functions can't modify
errno. It doesn't say this clearly even for strtol(). C90 and later
C standards say this clearly for strtol() but not many other functions
since not many other functions need this in plain C. POSIX only says this
indirectly even for strtol() by saying that it defers to the C standard
unless stated otherwise. But POSIX has many functions that need this
statement, starting with read() with sizes > SSIZE_MAX on implementations
that support such sizes. (read() is very hard to use if you use such
sizes with it. v7 had the correct arg type (int) to disallow such sizes.
Now read() is only safe to use by avoiding such sizes. This is easy to
do in applications but not in libraries.)
>> I agree that it would be more
>> consistent for ptrace(2) to not do that as well, but the behaviour is
>> already there for 35 years and I do not view the 'consistency' as a serious
>> reason to break ABI and introduce random failures for innocent consumers
>> of it.
>
> How hard it will be to bring ptrace() to what C99 expects? Perhaps now
> time is suited well to change some obsoleted things.
This should be safe to change, since portable applications like gdb can't
assume that the implemementation clobbers errno for them.
Even FreeBSD's man page doesn't document the FreeBSD behaviour. It
documents, with poor wording, that applications must set errno as usual:
%%%
RETURN VALUES
Some requests can cause ptrace() to return -1 as a non-error value; to
disambiguate, errno can be set to 0 before the call and checked
afterwards.
%%%
The poor wording is just "errno can be set to 0". It _must_ be set to 0.
Also, the function gurantees to not clobber errno so that this checking
is guaranteed to work.
FreeBSD's man page for strtol says nothing at all about either setting
errno before calls or the C90+ guarantees that make this useful.
> "conforming implementation may have extensions (including additional
> library functions), provided they do not alter the behavior of any
> strictly conforming program.3)"
>
> ptrace() is extension (additional library function) so can't set errno
> to 0 (it breaks strictly conforming program).
Use of ptrace() makes a program very far from stricty conforming. Only
quality of implementation requires ptrace() to follow the usual rules.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160828144742.G1008>