From owner-svn-src-head@freebsd.org Sun Aug 28 01:25:51 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 59F66A94D11 for ; Sun, 28 Aug 2016 01:25:51 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (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 0BD91AC8 for ; Sun, 28 Aug 2016 01:25:50 +0000 (UTC) (envelope-from mailing-machine@vniz.net) Received: by mail-lf0-f47.google.com with SMTP id l89so79570534lfi.1 for ; Sat, 27 Aug 2016 18:25:50 -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=BAniZ626rFJK/NorsYttLNGqMjB6+aATbLnvnv2RUAY=; b=VQDwNi5qqne0pJ4jqTpvCcdZCSRGjMCe9OMLs6n6qZY5JXfVw3LuGy5Jkn87XBXmDJ w5blitMBowN27io55VjAWN4FsCKFQu+l9SN/VDum/ME3CpOysCuNCYLlEPTxIfAYkexx W/1tpSIv0SkfiM2JlpE++1rgcgzco/nRdwTPR9AWGVJ11tjGudEDduZ86e8338BghPdw ufpq/LHkl6k7MnLC/vjTZsynqHFwfFJr/pmZZip0tyZ4Hr2LF7DhaCib6are5syJFpaD W2EYV+ymHK9QjXBzSitp/tM8vhfwzWuNXlodXYxaLV5cLtAsCyg1oY9SAWEBxPF/PDkq LsUA== X-Gm-Message-State: AE9vXwPVR3nnGjRatBtfHD+4orCPjnlD5A3YSnPyQJvXSF/2WkN4qShnWFzl4RqaczatCg== X-Received: by 10.25.19.169 with SMTP id 41mr2903292lft.24.1472347548216; Sat, 27 Aug 2016 18:25:48 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by smtp.gmail.com with ESMTPSA id i80sm5326519lfg.6.2016.08.27.18.25.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Aug 2016 18:25:47 -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> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Andrey Chernov Message-ID: <80ad9e03-74bc-8c99-666f-787772bef2b9@freebsd.org> Date: Sun, 28 Aug 2016 04:25:46 +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: <20160828011501.GH83214@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 01:25:51 -0000 On 28.08.2016 4:15, Konstantin Belousov wrote: >> POSIX: "No function in this volume of POSIX.1-2008 shall set errno to zero." > I am quite curious where ptrace(2) is defined by POSIX. POSIX just repeats C99 statement for its own functions, supporting this rule too, but C99 rule is more general and related to any library functions. >> 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." >> C99 statement sounds stricter: >> "The value of errno is zero at program startup, but is never set to zero >> by any library function. 176)" >> And syscall is not different from library function from C99 point of view. > Point me to a single line in C99 which mentions ptrace(). > > Do you understand what did the commit changed, and what it did not ? > Setting errno to zero before the syscall was the existing behaviour > before the change, and I did not modified anything there. But previous > wrapper set errno to zero in main thread even if called from some other > thread, which was the bug fixed. If you may notice, I don't blame you and don't say that you introduce setting errno to 0. I just want to bring your attention to the problem while you are in that area and familiar with it.