[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: insert-header-preprocessor-definition

From: Ben Bacarisse
Subject: Re: insert-header-preprocessor-definition
Date: Sun, 15 Apr 2018 02:02:56 +0100

Emanuel Berg <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]