From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.devel Subject: Re: Using __builtin_expect (likely/unlikely macros) Date: Thu, 18 Apr 2019 18:56:22 +0100 Message-ID: References: <87a7gst973.fsf@gmail.com> <875zrgt12q.fsf@gmail.com> <6919a4c8-df76-ea1e-34db-1fa62a360e5a@cs.ucla.edu> <87h8aykdod.fsf@gmail.com> <4fa7885e-8c66-c7c4-ff71-a013505863af@cs.ucla.edu> <2dfb837d-989d-c736-b6e6-b20c0e940596@cs.ucla.edu> <87o956c4n4.fsf@gmail.com> <1fbd2fca-18f0-0a90-7a45-58419a9e11ee@cs.ucla.edu> <1555450070.23658.4@yandex.ru> <66b74701-012a-902e-4a5b-6bc30efa87c0@cs.ucla.edu> <313555ec-aef0-4892-f312-1a5d263a5df6@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="82937"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 18 19:57:06 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 1hHBHV-000LU0-So for ged-emacs-devel@m.gmane.org; Thu, 18 Apr 2019 19:57:06 +0200 Original-Received: from localhost ([127.0.0.1]:44948 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHBHU-0000Sx-Tf for ged-emacs-devel@m.gmane.org; Thu, 18 Apr 2019 13:57:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHBGy-0000Sf-Nl for emacs-devel@gnu.org; Thu, 18 Apr 2019 13:56:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hHBGx-00072o-P3 for emacs-devel@gnu.org; Thu, 18 Apr 2019 13:56:32 -0400 Original-Received: from [195.159.176.226] (port=57342 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hHBGx-000727-IA for emacs-devel@gnu.org; Thu, 18 Apr 2019 13:56:31 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hHBGu-000KqN-QL for emacs-devel@gnu.org; Thu, 18 Apr 2019 19:56:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:uGfvKDgYFfMn0ATQEONtuhktpYI= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:235629 Archived-At: On Thu 18 Apr 2019, Paul Eggert wrote: > On 4/18/19 6:47 AM, Andy Moreton wrote: >> Please don't use this macro, as it makes the code much less readable. >> >> It is reasonable to have a macro that combines the '_Noreturn' and >> 'ATTRIBUTE_COLD' decorations, but that should not be combined with the >> return type. > > Actually I first tried it the way that you suggested, but found that > having a single macro improved readability for me, partly because > _Noreturn functions don't return anything so their return type doesn't > matter except for static type checking. 'AVOID' lets a traditionalist > reader easily see that the type 'void' is intended, while also connoting > that the function is rarely used because calls to it are normally > avoided. (I tried to shoehorn "cold" and "does not return" into the > macro's name too, but couldn't come up with anything better than > "AVOID_SKIJUMP". :-) I had an entirely different impression: AVOID is a weird name for a return type, so where is the return type, and does this even compile ? In addition, using this macro makes it entirely non-obvious that the function has a "_NoReturn" specifier, making it harder for the reader to understand the intended semantics. I have no objection to adding "noreturn" and "noreturn_cold" macros if that helps, but the "AVOID" macro should be avoided as harmful to readability. AndyM