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:17:53 +0300 Message-ID: <1555723073.16908.1@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> <1555722559.16908.0@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="79237"; 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:27:21 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 1hHemm-000KTM-33 for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Apr 2019 03:27:20 +0200 Original-Received: from localhost ([127.0.0.1]:35312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHemk-0003iN-Rc for geb-bug-gnu-emacs@m.gmane.org; Fri, 19 Apr 2019 21:27:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHemd-0003hr-MK for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 21:27:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hHeek-0002Hi-Q5 for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 21:19:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59837) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hHeek-0002Hb-MW for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 21:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hHeek-0006qh-92 for bug-gnu-emacs@gnu.org; Fri, 19 Apr 2019 21:19:02 -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:19:02 +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.155572308326259 (code B ref 35062); Sat, 20 Apr 2019 01:19:02 +0000 Original-Received: (at 35062) by debbugs.gnu.org; 20 Apr 2019 01:18:03 +0000 Original-Received: from localhost ([127.0.0.1]:45147 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHedn-0006pS-Eo for submit@debbugs.gnu.org; Fri, 19 Apr 2019 21:18:03 -0400 Original-Received: from forward104p.mail.yandex.net ([77.88.28.107]:39691) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hHedl-0006ox-B7 for 35062@debbugs.gnu.org; Fri, 19 Apr 2019 21:18:02 -0400 Original-Received: from mxback11j.mail.yandex.net (mxback11j.mail.yandex.net [IPv6:2a02:6b8:0:1619::84]) by forward104p.mail.yandex.net (Yandex) with ESMTP id 88F614B0024D; Sat, 20 Apr 2019 04:17:55 +0300 (MSK) Original-Received: from smtp4j.mail.yandex.net (smtp4j.mail.yandex.net [2a02:6b8:0:1619::15:6]) by mxback11j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Kpp5L8EB1h-HtoCT49x; Sat, 20 Apr 2019 04:17:55 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1555723075; bh=JVnZUYNmWTco18iOF/m8CAMbEKg9zdtnv1XfYyoJKc4=; h=In-Reply-To:Cc:To:Subject:From:References:Date:Message-Id; b=nhrPJ4ThnWMYXl25J5hS2L12mdcO2zvKE9yt6rAMAp54UqR4bdxYkOZLPKyoVdNsh Qyi5acgic+N2BeBDECXxlv9mId7U4JDV3il8Pyu3KvrnDKgg/U2MnDt5dG/pV8djYC DSHVPATyrCm8bqA78H9gblLyClDD4Xzv4S+0yc9w= Authentication-Results: mxback11j.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by smtp4j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id lHfYNvStl1-HscCsVLT; Sat, 20 Apr 2019 04:17:54 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <1555722559.16908.0@yandex.ru> 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:157879 Archived-At: =F7 =F3=C2, =C1=D0=D2 20, 2019 at 04:09, Konstantin Kharlamov=20 =CE=C1=D0=C9=D3=C1=CC: >=20 >=20 > =F7 =F0=D4, =C1=D0=D2 19, 2019 at 17:31, Paul Eggert = =20 > =CE=C1=D0=C9=D3=C1=CC: >> I'd rather not use 'const' on locals. Let me tell you a story as to=20 >> =7Fwhy. >>=20 >> I once worked with someone who insisted on using the 'register'=20 >> =7Fkeyword on every C local variable that was never taken the address=20 >> =7Fof, on the grounds that this meant the reader could easily see that=20 >> =7Fthe variable could never be modified indirectly via a pointer and=20 >> =7Fthat this made the code easier to read because you didn't need to=20 >> =7Fworry about aliasing. >>=20 >> I disagreed then, and still disagree. Saying 'register' nearly all=20 >> =7Fthe time clutters up the code, and the cost is not worth the=20 >> benefit =7Fin C. It's pretty easy for a human reader to determine=20 >> whether a =7Flocal variable is taken the address of somewher in its=20 >> function. (If =7Fit's hard, then write an Elisp function that will=20 >> tell you. :-) In =7Fhindsight, perhaps C should have been designed so=20 >> that 'register' was =7Fthe default for local variables, and that one=20 >> needed a special word =7Fto say "watch out! this variable might have=20 >> its address taken!"; but =7Fthe ship has sailed. >>=20 >> 'const' is like 'register' in this respect. Putting 'const' nearly=20 >> =7Feverywhere clutters C code. It's pretty easy for a human reader to=20 >> =7Fdetermine whether a local variable is modified. >=20 > "const" is only similar to "register" in a way of having an=20 > additional word. Sure it's easy for a human to find whether variable=20 > was modified, but this requires to go through the whole function=20 > highlighting variable usages. Now imagine if visibility scope has=20 > lots of variables? This is especially relevant for the old C89 style=20 > where every variable was declared at the beginning of a function. >=20 > And btw, current workflow with searching through the body doesn't=20 > work well in vanilla Emacs. While other editors allow you to=20 > highlight matches by putting a caret over a symbol, Emacs requires=20 > either manually making it highlight/unhighlight, or installing a=20 > separate package highlight-symbol.el which is a bit buggy and wasn't=20 > updated since 2016. That is to say, having non-modified things=20 > declared with "const" may help an average Emacs developer. Shameless plug here: I'm using "color-identifiers" package, which=20 colors variables in different colors. This is an amazing help! Still,=20 unfortunately a number of immediately clear distinct colors is quite=20 limited, so I'm still often use highlight-symbol.el functional. =