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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
