bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral


From: Paul Eggert
Subject: Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral
Date: Sun, 10 Oct 2010 20:55:51 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8

On 10/10/2010 03:50 PM, Bruno Haible wrote:
> From this past experience, I estimate the risk of having a collision with a
> system header by using a __ prefix as higher than the risk of having a 
> collision
> with a user program by using a _ prefix.

That sounds like reasonable advice given your experience, thanks.

However, it's not just __.  From a Standard C point of view,
all prefixes of the form _[_A-Z] are in the same category, so names
like _FOO cannot be defined by user code, just as names like __foo
and __FOO are disallowed.  Also, all external identifiers beginning
with _ must be avoided as well.  These prohibitions have been in place
since C89.

C99 has also prohibited the use of all identifiers beginning with _
in file scope, in both the ordinary and tag name spaces.  Hence
any top-level struct in our code must have a tag that does not begin
with _.  This extra prohibition is not in C89, and I don't know of
any C99 library implementation that takes advantage of it, but it's
hard to imagine that the prohibition was added to C99 for no reason.

This leaves us in a tight spot: except for member names, our files
can't define useful identifiers that begin with _ without violating C99.
On the other hand, our .h files do that regularly without serious
problems, and it'd be quite a hassle to change all those names.

Perhaps it'd help if we documented these naming issues in the gnulib
manual somewhere.  I doubt whether we can come up with strict rules
that will keep everybody happy and are guaranteed to work everywhere,
but it wouldn't hurt to at least document the issues.

I should also mention that when it comes to time.h we are already
violating the C Standard, as the standard prohibits an application
from including its own header named "time.h".  But there's not much
we can do about _that_, other than document it.



reply via email to

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