From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by sourceware.org (Postfix) with ESMTPS id EA0DD3947C29 for ; Mon, 5 Dec 2022 18:53:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EA0DD3947C29 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 722293200913 for ; Mon, 5 Dec 2022 13:53:49 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 05 Dec 2022 13:53:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1670266428; x= 1670352828; bh=ZeJkHbi0l/FOgH0H8OF0gENi/Tczeqp9U11WBRNsbvU=; b=h x5KFxzVe5bI+hAtX+voZqroSSvNDs+G11GAmwP1EL72u8lN54bvlnZF1cc4F8LHs YmSnGrRJzBg9a79AEjv1MMezLWozLVjhKCXgpwMexKWcx37c15aKsg2R96Arzr0C 3OmhvUlfVdc5eTi24QmIgWdwYi5nMRJW9HLGQ41Ttjsy2zTJuUCsb+TY3flyMea3 midijUOBZ7VhlWOdubZaDMhHr+vhAOHQuA2vi4KHqg3EsIMAO3IUI2Q8wfrzkx4M UmDg9imrBI90SY8jg4/ELi5ySeEo/I5Gk77b07I99cKhJRCvpKXf8tRvYzIHsXmm noQCrXcy2+cy7AMuQTiXw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1670266428; x=1670352828; bh=Z eJkHbi0l/FOgH0H8OF0gENi/Tczeqp9U11WBRNsbvU=; b=WiZqezoWMU+Vcq3NW qpPvTvJVnFwbHJ9L2yTL2QKz6kBheckMsF5hIQN1pU2xZAjs3iRnohDyvHftLY7N mdnGRti4bf41Qjv9frAWV7frij5z/jpfH6KXwpURnU+XeTI4oNII+T057M+C/QH0 Asrg1ePHys9FUmAvZa4yo8Rht1Bx0huvBgkAonvT3dWwsOcvsibMBw4TJBOEVvKM mDKS0F80ilJh/S4X3zKgdt1K4y/7DFInxURGQW3DY4xbjEAyXE75YpfFj4+fOiXn y4xWAAH364duTcwcRtpENh77wk4qVCvRvg2CUuUI7t9xqk/mEKq59c3t35FxxDML sN7Gw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudeggdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtje ertddtfeejnecuhfhrohhmpegkrggtkhcuhggvihhnsggvrhhguceoiigrtghksehofihl fhholhhiohdrohhrgheqnecuggftrfgrthhtvghrnhepgedvueegveefudfhvdffudejhf fgleektdduvdeffedvueeuhfduiefgtdevjeefnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Mon, 5 Dec 2022 13:53:48 -0500 (EST) Message-ID: Date: Mon, 5 Dec 2022 13:53:48 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: bind(2): Missing [[gnu::nonnull]] Content-Language: en-US To: libc-alpha@sourceware.org References: <8292ef824696e0fbac4f4ed036aad43c0458b8a2.camel@xry111.site> <87wn78cnpe.fsf@igel.home> <4e085ada-10eb-9de9-7681-1c96ec74da30@gmail.com> <87y1rnf1mw.fsf@oldenburg.str.redhat.com> From: Zack Weinberg In-Reply-To: <87y1rnf1mw.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2022-12-04 1:46 PM, Florian Weimer via Libc-alpha wrote: > * Alejandro Colomar via Libc-alpha: >> On 12/4/22 06:59, Xi Ruoyao wrote: >>> On Sat, 2022-12-03 at 20:05 +0100, Andreas Schwab wrote: >>>>> Currently the man page says: >>>> >>>> You can never depend on EFAULT for invalid addresses. >>> Hmm, is this documented somewhere? >> >> I don't know, but let me have an educated guess: >> >> Holding a pointer to invalid memory is Undefined Behavior by the >> standard, except if that pointer is NULL, or is still indeterminate >> because the pointer has not yet been initialized with a valid address. >> Using an uninitialized pointer is UB as using any uninitialized >> variable. Using a NULL pointer is only okay for comparisons, or as a >> sentinel value, but never for accessing memory. So chances are high >> that the program will already have invoked UB at the time bind(2) is >> called with an invalid address. > > Currently, Linux does not report for vDSO-accelerated system calls, but > generates SIGSEGV. We received bug reports when we added vDSO support > for time/gettimeofday/clock_gettime because some tests were relying on > the EFAULT behavior. I don't have time to dig through POSIX and find it now, but I'm like 95% sure there's explicit wording to the effect that the OS is allowed to send SIGSEGV under any circumstance that's documented to result in an EFAULT error, and vice versa. That should be good enough for the _manpages_, but I think the _headers_ probably need to be more cautious about adding annotations that can cause compilers to draw new inferences about which control flow paths are unreachable. I imagine this would be a hard sell with the "never break userspace" crowd but I would _like_ Linux to at least have a mode in which it would always send SIGSEGV rather than producing EFAULT. It seems like it would be helpful for debugging. zw