From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ben Bacarisse Newsgroups: gmane.emacs.help Subject: Re: insert-header-preprocessor-definition Date: Sun, 15 Apr 2018 02:02:56 +0100 Organization: A noiseless patient Spider Message-ID: <871sfhp9hb.fsf@bsb.me.uk> References: <86fu429udy.fsf@zoho.com> <87lgdt21a4.fsf@bsb.me.uk> <86zi29earx.fsf@zoho.com> <87y3htzclf.fsf@bsb.me.uk> <86po317392.fsf@zoho.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1523754212 11492 195.159.176.226 (15 Apr 2018 01:03:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Apr 2018 01:03:32 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Apr 15 03:03:28 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f7W4l-0002sJ-8M for geh-help-gnu-emacs@m.gmane.org; Sun, 15 Apr 2018 03:03:28 +0200 Original-Received: from localhost ([::1]:52767 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f7W6q-0003z2-8o for geh-help-gnu-emacs@m.gmane.org; Sat, 14 Apr 2018 21:05:36 -0400 Original-Path: usenet.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!feeder.erje.net!2.eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 38 Original-Injection-Info: reader02.eternal-september.org; posting-host="55e0f35077281f3197e31e8f5f71ad20"; logging-data="4959"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18TEMpUgvVF1Ht/V+kGm/81aQIkRtkmdXQ=" Cancel-Lock: sha1:8uROAdGNDaHNqehcecu9SAcgTuc= sha1:baBBoQ73gUx9p3qe9a9Ffua6Pks= X-BSB-Auth: 1.4b84246519253b58331a.20180415020256BST.871sfhp9hb.fsf@bsb.me.uk Original-Xref: usenet.stanford.edu gnu.emacs.help:222397 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:116515 Archived-At: Emanuel Berg writes: > Ben Bacarisse wrote: > >> That is safe, yes. Doing it by hand, I think >> most people write H_COLOR [...] Actually, >> I like the symmetry > > I like symmetry too but not for symmetry's > sake, so I removed the part that transformed > ".h" into "_H" - which, ironically, I didn't > put there for the symmetry! Anyway now it is > just H_COLOR. [1] > > Also, altho I've thought about this on and off > since I heard of it, I have failed to come to > terms with the underlying issue. How can > COLOR_H lead to an error when H_COLOR (or > H_COLOR_H) doesn't? Yes, COLOR_H is almost certainly safe too. The issue is to find a general rule that works regardless of the file name. The C standard lists, for every header, any patterns of macro names that are reserved to the implementation. errno.h, for example, reserves all macro names that start E followed by a digit or another upper case latter. Thus a program that uses ERROR_H whilst also including errno.h is technically undefined even if errno.h does not actually use that macro name. None of the headers reserve any names that start H_ so that pattern happens to be safe. There are lots of other ways to start the macro name that will also be safe, but H_ has a certain appeal and is popular with people who worry about the letter of the law. -- Ben.