From owner-svn-src-head@freebsd.org Sun Aug 28 02:33:22 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13F92B77D5C for ; Sun, 28 Aug 2016 02:33:22 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93552BB3 for ; Sun, 28 Aug 2016 02:33:21 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f50.google.com with SMTP id b199so80037903lfe.0 for ; Sat, 27 Aug 2016 19:33:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NON1t5R/nN2n6ClujeeLcFiTYZBCvrnoxi/8ATI5rPM=; b=KRtuejpHzeINIz/IdA9l2CswM1Zdsr4GYWtn5LZyGs/qBj8CYRExa22pJ+gEU8t/OK US7+NIAaQEg4oXigEmbRoFbMLknKTKHfIuuTt510TwiwpKNBkLjlVT0vbsHqC8UV/BIs +umPi93Gg2bzSN4epZ7XgFo0CgT3tRnof97HPEr4wKarJdK1gYUIPGBuY2h8qTnjUMcJ dIOw4VI9WDVsIh433W+w+pKWWaeJnECFh82nz5Ho8z8W8np0M15BqD3hfVYGeGqEaXL8 a8SKw8fn2IfJQo4U1zvvbiejx3GTAyNIWOZ9n8js88FPoR6PZRKXd/Xyuy05ZzmrCU9D 1uaA== X-Gm-Message-State: AE9vXwMxaNHZNK/YC9SxNb6kPPKjJi0Mk2nEZNkQVKO1C2bRGlwYVQViyN2gGV+7Z0FJQA== X-Received: by 10.25.144.8 with SMTP id s8mr3664485lfd.94.1472351599257; Sat, 27 Aug 2016 19:33:19 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id g69sm5268331lji.44.2016.08.27.19.33.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Aug 2016 19:33:18 -0700 (PDT) Subject: Re: svn commit: r304928 - in head/lib/libc: amd64/sys i386/sys sys To: Konstantin Belousov 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> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Andrey Chernov Message-ID: <70b3b052-4c29-c332-14bf-e50847636a8a@freebsd.org> Date: Sun, 28 Aug 2016 05:33:17 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160828015210.GI83214@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 02:33:22 -0000 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).