From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 74f54af: Use eassume (false) for branch that's never taken. Date: Tue, 23 Apr 2019 09:19:22 +0300 Message-ID: <837ebl5jmd.fsf@gnu.org> References: <83ftqecrms.fsf@gnu.org> <83ef5ycnny.fsf@gnu.org> <9b3a1717-64de-795a-2acf-0698576caf02@cs.ucla.edu> <83zholbvnb.fsf@gnu.org> <25791a2b-260e-9cee-b454-5d9f53fa33e0@cs.ucla.edu> <83r29xb3co.fsf@gnu.org> <27636c2b-549d-4e78-a1e3-af78605ebd1e@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="253601"; mail-complaints-to="usenet@blaine.gmane.org" Cc: phst@google.com, p.stephani2@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 23 08:19:39 2019 Return-path: Envelope-to: ged-emacs-devel@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 1hIomI-0013rq-Pu for ged-emacs-devel@m.gmane.org; Tue, 23 Apr 2019 08:19:38 +0200 Original-Received: from localhost ([127.0.0.1]:48787 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIomH-0007am-9Q for ged-emacs-devel@m.gmane.org; Tue, 23 Apr 2019 02:19:37 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIomB-0007ag-4M for emacs-devel@gnu.org; Tue, 23 Apr 2019 02:19:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hIomA-0002ak-K6; Tue, 23 Apr 2019 02:19:30 -0400 Original-Received: from [176.228.60.248] (port=2454 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hIomA-0006Kc-1V; Tue, 23 Apr 2019 02:19:30 -0400 In-reply-to: <27636c2b-549d-4e78-a1e3-af78605ebd1e@cs.ucla.edu> (message from Paul Eggert on Mon, 22 Apr 2019 17:52:32 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235799 Archived-At: > From: Paul Eggert > Cc: p.stephani2@gmail.com, phst@google.com, emacs-devel@gnu.org > Date: Mon, 22 Apr 2019 17:52:32 -0700 > > { > int i = 27; > eassume (i == 27); > return 1000 / i; > } > > Would we reject this solution because "if it's _really_ impossible, then > eassume has no place there"? No, because it really *is* impossible for > i != 27 there; but in this (very contrived) example, eassume *does* have > a place, namely to pacify the amazingly dumb compiler. > > The case that started this thread is similar, except that GCC is not as > dumb as in the contrived example above. > > One might at first think that because the programmer might have made a > mistake and it's better to be safe than sorry, we should replace > instances of 'eassume (X);' with 'if (!X) emacs_abort ();' so that there > is always a runtime check, even in production. But that would be > overkill, for the same reason that replacing all instances of 'eassert > (X);' with 'if (!X) emacs_abort ();' would be overkill. My mental model of using assertions in Emacs is slightly different. In my model, we use eassert for things that "cannot happen", but can be tolerated in some sense in a production build. "Tolerate" here means that the result could be incorrect display or some strange error message or a crash in some unrelated place. If something that "cannot happen" causes an immediate problem, i.e. the code simply cannot continue, then we should call emacs_abort instead. eassume is the same as eassert, it just helps the compiler generate better code in optimized builds, so conceptually it isn't different, to my mind. I learned long ago that in programming, "things which cannot happen, will", so I don't consider calling emacs_abort overkill where appropriate. > By the way, now that we have -fsanitize=undefined, it would be realistic > to simplify Emacs by dropping 'eassume' and replacing all uses with > plain 'assume', as modern compilers will do the runtime check for us > automatically (if we use -fsanitize=reachable), and older compilers are > kind of lost causes anyway. If non-production builds use -fsanitize=reachable, and if doing so will cause an abort when the condition is violated, then yes, maybe we should do that. We still have eassert, though. And it doesn't help that with current build machinery one needs to manually specify all the compiler switches, instead of using some simple configure switch that automatically does that for us. Using one more switch increases that burden slightly.