[Top][All Lists]
[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.
- Re: [coreutils] [PATCH 2/2] stat: print timestamps to full resolution, Eric Blake, 2010/10/08
- Re: [coreutils] [PATCH 2/2] stat: print timestamps to full resolution, Jim Meyering, 2010/10/08
- [PATCH] time: enforce recent POSIX ruling that time_t is integral, Eric Blake, 2010/10/08
- Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral, Bruno Haible, 2010/10/09
- Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral, Paul Eggert, 2010/10/09
- Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral, Bruno Haible, 2010/10/10
- Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral, Paul Eggert, 2010/10/10
- Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral, Paul Eggert, 2010/10/10
- Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral, Bruno Haible, 2010/10/10
- Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral,
Paul Eggert <=
- Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral, Bruno Haible, 2010/10/10
- Re: [PATCH] time: enforce recent POSIX ruling that time_t is integral, Paul Eggert, 2010/10/10
- [PATCH] Fix mismatched parens in previous commit, Gary V. Vaughan, 2010/10/11
- Re: [PATCH] Fix mismatched parens in previous commit, Jim Meyering, 2010/10/11
- Re: [PATCH] Fix mismatched parens in previous commit, Gary V. Vaughan, 2010/10/11
- Re: [PATCH] Fix mismatched parens in previous commit, Paul Eggert, 2010/10/11
- [PATCH] rewrite int foo[2*X-1] to verify(X) or to int foo[X?1:-1], Paul Eggert, 2010/10/10
- Re: [PATCH] rewrite int foo[2*X-1] to verify(X) or to int foo[X?1:-1], Bruno Haible, 2010/10/10
- Re: [PATCH] rewrite int foo[2*X-1] to verify(X) or to int foo[X?1:-1], Paul Eggert, 2010/10/10