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

2010-10-10 Thread Paul Eggert
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 e

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

2010-10-10 Thread Bruno Haible
Paul Eggert wrote: > > But why use __ as prefix? Symbols starting with __ are, generally speaking, > > in the territory of the implementation (libc + compiler), which is why > > gnulib > > tries to use only symbols that start with a single _. > > But this symbol will appear in , so it has both fl

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

2010-10-10 Thread Bruno Haible
Paul Eggert wrote: > * lib/time.in.h (struct __time_t_must_be_integral): Rewrite > 2 * ((time_t) 1 / 2 == 0) - 1 to (time_t) 1; this suffices to > verify that time_t cannot be floating. I disagree that this is enough. The C standard says that a cast to floating- point types cannot be portably used

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

2010-10-10 Thread Paul Eggert
On 10/10/2010 02:15 PM, Bruno Haible wrote: > I disagree that this is enough. The C standard says that a cast to floating- > point types cannot be portably used in integer constant expressions. But a > compiler is free to support this, as an extension. By the same argument, a compiler is also free

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

2010-10-10 Thread Paul Eggert
Bruno Haible wrote: > But why use __ as prefix? Symbols starting with __ are, generally speaking, > in the territory of the implementation (libc + compiler), which is why gnulib > tries to use only symbols that start with a single _. But this symbol will appear in , so it has both flavors: from g

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

2010-10-10 Thread Paul Eggert
On 10/10/2010 05:09 AM, Bruno Haible wrote: > I agree now. Thanks for checking that. I applied the following patch accordingly. In a later message I'll follow up with a few more proposed patches. >From 6c74aa7b6196c9b3d650c499ea02f1dfc1b62491 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun

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

2010-10-10 Thread Bruno Haible
Hi Paul, ` > >> Hmm, given Bruno's recent point that C89 didn't require ?: support > >> in constant expressions > > I'm skeptical of that. I can't find my copy of the official C89 standard, > but the draft says that > constant expressions can contain ?:. In

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

2010-10-09 Thread Paul Eggert
>> Hmm, given Bruno's recent point that C89 didn't require ?: support >> in constant expressions I'm skeptical of that. I can't find my copy of the official C89 standard, but the draft says that constant expressions can contain ?:. In fact, the grammar in s

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

2010-10-09 Thread Bruno Haible
Hi Eric, Thanks for this addition. > +struct __time_t_must_be_integral { > + unsigned int __floating_time_t_unsupported : 2 * ((time_t) 1 / 2 == 0) - 1; > +}; I agree with the expression (personally I would have used (time_t) 0.5 == 0 but that's probably equivalent). But why use __ as prefix?

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

2010-10-08 Thread Eric Blake
* lib/time.in.h (__time_t_must_be_integral): Detect any problematic systems, allowing the rest of gnulib to assume POSIX. Signed-off-by: Eric Blake --- > > oppose a patch that adds a compile-time verification in gnulib's > > that time_t is integral on all platforms that we support, > > given th