Date: Sun, 28 Aug 2016 05:33:17 +0300 From: Andrey Chernov <ache@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: 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: <70b3b052-4c29-c332-14bf-e50847636a8a@freebsd.org> In-Reply-To: <20160828015210.GI83214@kib.kiev.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. >> Already done: ptrace == "any library function". > *Shaking head* > > 'Library functions' references in the context of C99/C11 are implicitely > limited to the functions defined by the chapter 7 Library of the standard. No, they are limited to the libraries described in ISO/IEC International Standards family which have C standard library among them. C standard library described in ANSI C standard which is: ISO/IEC (1999). ISO/IEC 9899:1999(E): Programming Languages. libc is C standard library with extensions, and C99 directly says about them: "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). > To play this sillyness to the end, please answer whether I am allowed to > provide static functions definitions in the libraries headers ? E.g. clause > 7.1.2 6 of C11 says: > Any declaration of a library function shall have external linkage. You can, as long as your static function (i.e. extension) do not alter the behavior of any strictly conforming program (see the quote above).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70b3b052-4c29-c332-14bf-e50847636a8a>