From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id A025D385803F for ; Tue, 22 Jun 2021 08:25:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A025D385803F Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 02A10D6E; Tue, 22 Jun 2021 01:25:59 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4A2493F718; Tue, 22 Jun 2021 01:25:58 -0700 (PDT) From: Richard Sandiford To: Kees Cook Mail-Followup-To: Kees Cook , Qing Zhao , Richard Biener , gcc-patches Qing Zhao via , richard.sandiford@arm.com Cc: Qing Zhao , Richard Biener , gcc-patches Qing Zhao via Subject: Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc References: <41B59ACD-94E9-45A4-9BB5-84154FAB6DAE@oracle.com> <25A77D77-5251-46EC-8E46-2F19B8BC510A@oracle.com> <42063D5B-FD16-47A0-833C-7730B0E0B700@oracle.com> <24CC2004-E379-4988-AC38-0EAAD9892862@oracle.com> <202106181644.1AF193B2@keescook> <202106210916.DCC72C72@keescook> Date: Tue, 22 Jun 2021 09:25:57 +0100 In-Reply-To: <202106210916.DCC72C72@keescook> (Kees Cook's message of "Mon, 21 Jun 2021 09:18:45 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 08:26:00 -0000 Kees Cook writes: > On Mon, Jun 21, 2021 at 03:39:45PM +0000, Qing Zhao wrote: >> So, if =E2=80=9Cpattern value=E2=80=9D is =E2=80=9C0xFFFFFFFFFFFFFFFF=E2= =80=9D, then it=E2=80=99s a valid canonical virtual memory address. Howeve= r, for most OS, =E2=80=9C0xFFFFFFFFFFFFFFFF=E2=80=9D should be not in user = space. >>=20 >> My question is, is =E2=80=9C0xFFFFFFFFFFFFFFFFF=E2=80=9D good for pointe= r? Or =E2=80=9C0xAAAAAAAAAAAAAAAA=E2=80=9D better? > > I think 0xFF repeating is fine for this version. Everything else is a > "nice to have" for the pattern-init, IMO. :) Sorry to be awkward, but 0xFF seems worse than 0xAA to me. For integer types, all values are valid representations, and we're relying on the pattern being =E2=80=9Cobviously=E2=80=9D wrong in context. = 0xAAAA=E2=80=A6 is unlikely to be a correct integer but 0xFFFF=E2=80=A6 would instead be a =E2=80=9Cnice=E2=80=9D -1. It would be difficult to tell in a debugger tha= t a -1 came from pattern init rather than a deliberate choice. I agree that, all other things being equal, it would be nice to use NaNs for floats. But relying on wrong numerical values for floats doesn't seem worse than doing that for integers. 0xAA=E2=80=A6 for float is (if I've got this right) -3.0316488252093987e-13, which admittedly doesn't stand out as wrong. But I'm not sure we should sacrifice integer debugging for float debugging here. Thanks, Richard