From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id DB7033858408 for ; Tue, 28 May 2024 15:20:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DB7033858408 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DB7033858408 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716909640; cv=none; b=HuOdSFQaew5B87fOVq+kR/xp7klpPtSrTpQLBpY6cQxGG0ybNKeJL8mCcnmRSQLd2N/Dut5kda2Ni7/Plf3U30p6E8wXh/WfS66KHypqvji7gIGLa79Qpx6KFSKIZsEhnNUwTm/Jl4TIQzowkx5eZ6OV9Ujroe+ou/mkbX+R6G4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716909640; c=relaxed/simple; bh=ZZT8uxhlbTPVIAUDKcvS19dpKUJoqNesQq57Mmq4e6Q=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=dTpJb8ywcM8sSbMZ4uRGqzjVeksUeM3/mPG+2l8c2Dc4kTIAXIkv5p2Jxp+zriUvuk05Xxyprvu657zJjjO8h89atPGJ+JymG+V5OQDVbzHkh3Qb0OjMqh9hhQeKLbKl7lixpTezTDtljOq0oBD7PlDtsBNHqqL+8gTVaGvQQnU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1716909632; bh=ZZT8uxhlbTPVIAUDKcvS19dpKUJoqNesQq57Mmq4e6Q=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=NZWdmtuu5W2GQL7kOoN44hSEY8cZJUYu1nBzBM0KJmqrkynVUOdHmIzTNQxb1wbWb dEtSCMkwQidLb40AvqyfOt9OcywMT7wgCiDPPJZmHXhx/WEq7ks11x1FZ5XdFW+235 25JIUy4sEBelL/n7Ys18uuIoyocQ4GsHJ8ZQ6d/A= Received: from [IPv6:240e:358:118b:9200:dc73:854d:832e:2] (unknown [IPv6:240e:358:118b:9200:dc73:854d:832e:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 9FF336705C; Tue, 28 May 2024 11:20:28 -0400 (EDT) Message-ID: <252b0ce7b2aa613d96b28dadcde80c84b3a700e6.camel@xry111.site> Subject: Re: Correct way of calling prctl(2) (was: Sashimi of prctl(2)) From: Xi Ruoyao To: Alejandro Colomar , libc-alpha@sourceware.org Cc: linux-man@vger.kernel.org Date: Tue, 28 May 2024 23:20:23 +0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.2 MIME-Version: 1.0 X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 Tue, 2024-05-28 at 11:24 +0200, Alejandro Colomar wrote: > From what I can see, glibc does no magic to set unspecified parameters > to 0, so this means passing '0' results in Undefined Behavior. On most targets where Glibc implements prctl in assembly (not C), the C standard does not apply at all so there's no Undefined Behavior.=20 There's just "expected" and "unexpected" behaviors. So on 32-bit targets (both long and int are 32-bit) there's no problem. On targets like riscv64 and loongarch64 the ABI mandates a sign- extension on parameters narrower than a GPR, so there's no problem as well. x86_64 does not have such a guarantee (as said in=C2=A0https://gcc.gnu.org/PR46942) so yes passing '0' may leave the high = 32 bits of the parameter uninitialized and cause problems (at least in theory). --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University