From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: master 8c81818673a 6/7: Tune volatile in read_char Date: Sat, 17 Aug 2024 17:03:26 +0000 Message-ID: <87zfpbgjz7.fsf@protonmail.com> References: <172386820621.30556.15409337288904485218@vcs2.savannah.gnu.org> <20240817041648.A6687C2BC66@vcs2.savannah.gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34026"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Paul Eggert To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 17 19:09:49 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sfMvz-0008i2-Uz for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Aug 2024 19:09:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sfMv5-0000W6-0J; Sat, 17 Aug 2024 13:08:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sfMpz-00075c-P3 for emacs-devel@gnu.org; Sat, 17 Aug 2024 13:03:36 -0400 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sfMpx-0006Qu-MH for emacs-devel@gnu.org; Sat, 17 Aug 2024 13:03:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1723914211; x=1724173411; bh=LxGjSBFJEBWmmGFyF/lDaxUiUK26L+oqy9V2Rjh5a+Y=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=pZ4fWFNoN31xEXUf+tw7B+FTA/vMIsd07n81IW0oHEgwFVNjeRE4/7ZYvCt04rF1E 7lbYBbZtazIHjyQqE5JGPNoITGVWcqHck8dSSN6vHy+IpHHihdFPVbaHz9K2afsAVt D2Xy3MfWh62jpiWG8m92T503eJL6nGfYMe7XtpnqrYVdsj2fWSaz2JTZG1SFFIhEJk JQoZ5d/T6CRkCvKNA3aLCSRSjozeDOoHevjIsCBZmfaNJN1SFZhTgFbE73oaBZxOeg P89YHhTQC/r53naWjI+YMuMgjVoRsVQOmRO+rrfcJNqlSeNR8cSM2gRT+UOtLVWUBz NBJ079jcGIn0Q== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0b7e11db9daffe28097f75219fcfc60e44bee3f5 Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@protonmail.com; helo=mail-40134.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 17 Aug 2024 13:08:47 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:322866 Archived-At: "Andrea Corallo" writes: > Paul Eggert writes: > >> branch: master >> commit 8c81818673ae9ff788c6e65fb90984f327b27964 >> Author: Paul Eggert >> Commit: Paul Eggert >> >> Tune volatile in read_char >> >> * src/keyboard.c (read_char): Optimize access to a local volatile. > > Hi Paul, > > this change building with "--enable-checking=3Dall > --enable-check-lisp-object-type" on my system (GCC 14 > x86_64-pc-linux-gnu) is introducing: > > "keyboard.c:2520:15: warning: variable =E2=80=98c=E2=80=99 might be clobb= ered by =E2=80=98longjmp=E2=80=99 or =E2=80=98vfork=E2=80=99 [-Wclobbered]" Well, GCC is late to the party, we already found that bug ;-) I think GCC, by its own logic, is right about this one. It doesn't know that local_getcjmp is local (and hasn't escaped), so it would be, in theory, possible for a signal handler to call 'longjmp' before c_volatile is initialized. And since GCC does not distinguish between the two branches following a 'setjmp', it might end up using the value of 'c' which might hypothetically have been clobbered. Of course there are many reasons that can't actually happen, but the GCC limitations are well known and we can work around them: diff --git a/src/keyboard.c b/src/keyboard.c index 0d3506bc59b..0992fab653b 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -2752,7 +2752,7 @@ read_char (int commandflag, Lisp_Object map, it *must not* be in effect when we call redisplay. */ =20 specpdl_ref jmpcount =3D SPECPDL_INDEX (); - Lisp_Object volatile c_volatile; + Lisp_Object volatile c_volatile =3D c; if (sys_setjmp (local_getcjmp)) { c =3D c_volatile; @@ -2800,7 +2800,6 @@ read_char (int commandflag, Lisp_Object map, goto non_reread; } =20 - c_volatile =3D c; #if GCC_LINT && __GNUC__ && !__clang__ /* This useless assignment pacifies GCC 14.2.1 x86-64 . */ Does that help? It does here, but these warnings are highly dependent on the precise GCC version and optimization flags used, which is why I still think we should default to -Werror=3Dclobbered to catch distributors performing LTO builds and such. Pip