From: Ben Bacarisse <ben.usenet@bsb.me.uk>
To: help-gnu-emacs@gnu.org
Subject: Re: insert-header-preprocessor-definition
Date: Sun, 15 Apr 2018 02:02:56 +0100 [thread overview]
Message-ID: <871sfhp9hb.fsf@bsb.me.uk> (raw)
In-Reply-To: 86po317392.fsf@zoho.com
Emanuel Berg <moasen@zoho.com> 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.
<anip>
--
Ben.
next prev parent reply other threads:[~2018-04-15 1:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <86fu429udy.fsf@zoho.com>
2018-04-11 15:47 ` insert-header-preprocessor-definition Ben Bacarisse
2018-04-11 20:41 ` insert-header-preprocessor-definition Emanuel Berg
2018-04-11 20:56 ` insert-header-preprocessor-definition Ben Bacarisse
2018-04-11 22:07 ` insert-header-preprocessor-definition Emanuel Berg
2018-04-14 23:54 ` insert-header-preprocessor-definition Emanuel Berg
2018-04-15 1:02 ` Ben Bacarisse [this message]
2018-04-15 7:44 ` insert-header-preprocessor-definition Yuri Khan
2018-04-15 19:35 ` insert-header-preprocessor-definition Emanuel Berg
2018-04-15 21:10 ` insert-header-preprocessor-definition Ben Bacarisse
2018-04-15 21:45 ` insert-header-preprocessor-definition Emanuel Berg
[not found] ` <mailman.12420.1523778312.27995.help-gnu-emacs@gnu.org>
2018-04-15 19:46 ` insert-header-preprocessor-definition Emanuel Berg
2018-04-16 5:35 ` insert-header-preprocessor-definition Yuri Khan
[not found] ` <mailman.12486.1523856961.27995.help-gnu-emacs@gnu.org>
2018-04-16 6:16 ` insert-header-preprocessor-definition Emanuel Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871sfhp9hb.fsf@bsb.me.uk \
--to=ben.usenet@bsb.me.uk \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).