From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.bugs Subject: bug#35062: [PATCH v3 2/3] constify a bit of xterm.c Date: Sat, 20 Apr 2019 04:09:19 +0300 Message-ID: <1555722559.16908.0@yandex.ru> References: <20190407021331.948-1-Hi-Angel@yandex.ru> <20190407021331.948-2-Hi-Angel@yandex.ru> <8336mml3s7.fsf@gnu.org> <1f700b05-16a8-1159-e2e3-61f9699981a1@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="8639"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35062@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 20 03:10:14 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hHeWD-00027w-6N for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2019 03:10:13 +0200 Original-Received: from localhost ([127.0.0.1]:35186 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHeWC-0001U5-3z for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Apr 2019 21:10:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHeW4-0001Tm-Nw for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 21:10:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hHeW2-0004c6-SO for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 21:10:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59813) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hHeW2-0004bT-02 for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 21:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hHeW1-0006d5-PS for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 21:10:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Apr 2019 01:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35062 X-GNU-PR-Package: emacs Original-Received: via spool by 35062-submit@debbugs.gnu.org id=B35062.155572257125440 (code B ref 35062); Sat, 20 Apr 2019 01:10:01 +0000 Original-Received: (at 35062) by debbugs.gnu.org; 20 Apr 2019 01:09:31 +0000 Original-Received: from localhost ([127.0.0.1]:45124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHeVW-0006cG-Oo for submit@debbugs.gnu.org; Fri, 19 Apr 2019 21:09:31 -0400 Original-Received: from forward102o.mail.yandex.net ([37.140.190.182]:57241) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHeVT-0006c2-VR for 35062@debbugs.gnu.org; Fri, 19 Apr 2019 21:09:29 -0400 Original-Received: from mxback19j.mail.yandex.net (mxback19j.mail.yandex.net [IPv6:2a02:6b8:0:1619::95]) by forward102o.mail.yandex.net (Yandex) with ESMTP id 95D0E6680D66; Sat, 20 Apr 2019 04:09:21 +0300 (MSK) Original-Received: from smtp4j.mail.yandex.net (smtp4j.mail.yandex.net [2a02:6b8:0:1619::15:6]) by mxback19j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id FJe1viKsYp-9L50FVU6; Sat, 20 Apr 2019 04:09:21 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1555722561; bh=iGr2rO9//J7vddOkUHY2rFv2K+MyVUm15QphM8qAkwM=; h=In-Reply-To:Cc:To:Subject:From:References:Date:Message-Id; b=KsabNQgpC8pLlycVOsa8Yc3mTATeOSBejJ1UCc1iNg4vY35WGx2S1H1U+qrjVt0ch XAE5DXXqEf4ngsH2IhVdcA3mJqWDJ1ZJ6P1bgZCkM4dX9YsvvDj/tpoxJ9NwQeDgdt HMAmrTdqjWnMYeAr+U5dRKEK3YAOgkj/uwKbwvtM= Authentication-Results: mxback19j.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by smtp4j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 521UY2Ztrn-9KcagTKv; Sat, 20 Apr 2019 04:09:20 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <1f700b05-16a8-1159-e2e3-61f9699981a1@cs.ucla.edu> X-Mailer: geary/emphasize-participated-in~g736c62cb X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:157878 Archived-At: =C2 =CF=F2, =E0=EF=F0 19, 2019 at 17:31, Paul Eggert =20 =ED=E0=EF=E8=F1=E0=EB: > I'd rather not use 'const' on locals. Let me tell you a story as to=20 > why. >=20 > I once worked with someone who insisted on using the 'register'=20 > keyword on every C local variable that was never taken the address=20 > of, on the grounds that this meant the reader could easily see that=20 > the variable could never be modified indirectly via a pointer and=20 > that this made the code easier to read because you didn't need to=20 > worry about aliasing. >=20 > I disagreed then, and still disagree. Saying 'register' nearly all=20 > the time clutters up the code, and the cost is not worth the benefit=20 > in C. It's pretty easy for a human reader to determine whether a=20 > local variable is taken the address of somewher in its function. (If=20 > it's hard, then write an Elisp function that will tell you. :-) In=20 > hindsight, perhaps C should have been designed so that 'register' was=20 > the default for local variables, and that one needed a special word=20 > to say "watch out! this variable might have its address taken!"; but=20 > the ship has sailed. >=20 > 'const' is like 'register' in this respect. Putting 'const' nearly=20 > everywhere clutters C code. It's pretty easy for a human reader to=20 > determine whether a local variable is modified. "const" is only similar to "register" in a way of having an additional=20 word. Sure it's easy for a human to find whether variable was modified,=20 but this requires to go through the whole function highlighting=20 variable usages. Now imagine if visibility scope has lots of variables?=20 This is especially relevant for the old C89 style where every variable=20 was declared at the beginning of a function. And btw, current workflow with searching through the body doesn't work=20 well in vanilla Emacs. While other editors allow you to highlight=20 matches by putting a caret over a symbol, Emacs requires either=20 manually making it highlight/unhighlight, or installing a separate=20 package highlight-symbol.el which is a bit buggy and wasn't updated=20 since 2016. That is to say, having non-modified things declared with=20 "const" may help an average Emacs developer. > (if it's hard, write an Elisp function :-) But situation in there is similar: declaring a local variable requires=20 to use (let=85), which means that even if you use variable once in the=20 end of a function, the variable will be visible to everything else. And=20 it's not like you can can make it immutable either. > In hindsight, perhaps C should have been designed so that 'const'=20 > was the default for local variables; but the ship has sailed there=20 > too. Yeah=85 FWIW, there's an "REmacs" effort on rewriting Emacs from C to=20 Rust, Rust has everything "const" by default. I'm sure emacs-devel=20 would largely disagree on integrating it because Rust isn't stable yet=20 (despite being widely deployed) and there's no GCC backend (LLVM only),=20 which are reasonable points. Still, I'm hoping at some point it will=20 change :) =