tzcode2007h.tar.gz - Functions defined with prototypes and C99 features?
In the tzcode2007h.tar.gz file, there is (at least) one function that is defined in prototype notation: static time_t hunt(char *name, time_t lot, time_t hit) It seems to me that the code assumes that there is a 64-bit integer type (int_fast64_t (function detzcode64()), though the code goes through some machinations to find a 64-bit integer and doesn't outright assume C99 compliance. Is there actually a good reason not to write the whole library with ISO prototypes? And lose the historically necessary but now unnecessary P macro for declaring functions with (or without) prototypes. Which platform(s) do not provide a C compiler that is capable of handling prototypes? I know of none on the major platforms...Unix, Linux, Windows (though maybe the bundled C compiler on HP-UX is still unaware, but that is intended for linking kernels, not program development). -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
"Jonathan Leffler" <jonathan.leffler@gmail.com> writes:
Is there actually a good reason not to write the whole library with ISO prototypes?
Not these days, no. Every practical C compiler supports prototypes nowadays. I think that stuff is now pedantic only, meant as illustration, to port back to ancient K&R compilers. As long as we're being pedantic, it might be worth mentioning that the current approach is not portable to arbitrary standard C platforms, since it assumes that time_t is at least as wide as int. C does not allow this: static int differ_by_repeat(time_t t1, time_t t0); static int differ_by_repeat(t1, t0) const time_t t1; const time_t t0; { ... } when time_t is of type 'short', say. (This is only a pedantic point as well, of course; nobody defines time_t to be that narrow.)
On a somewhat related note, I find that if I don't apply the following patch, I get a compiler warning: diff -r -u /tmp/tz/localtime.c tz/localtime.c --- /tmp/tz/localtime.c 2007-08-20 07:47:41.000000000 -0700 +++ tz/localtime.c 2007-11-06 09:35:20.712010000 -0800 @@ -328,7 +328,7 @@ if (TYPE_INTEGRAL(time_t) && TYPE_BIT(time_t) - TYPE_SIGNED(time_t) < SECSPERREPEAT_BITS) return 0; - return t1 - t0 == SECSPERREPEAT; + return ((int_fast64_t) t1) - t0 == SECSPERREPEAT; } static int This is the warning that I get: tz/localtime.c: In function 'differ_by_repeat': tz/localtime.c:331: warning: comparison is always false due to limited range of data type Would you please include this patch in the next release? Thank you, Erik van der Poel On Nov 6, 2007 9:25 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
"Jonathan Leffler" <jonathan.leffler@gmail.com> writes:
Is there actually a good reason not to write the whole library with ISO prototypes?
Not these days, no. Every practical C compiler supports prototypes nowadays. I think that stuff is now pedantic only, meant as illustration, to port back to ancient K&R compilers.
As long as we're being pedantic, it might be worth mentioning that the current approach is not portable to arbitrary standard C platforms, since it assumes that time_t is at least as wide as int. C does not allow this:
static int differ_by_repeat(time_t t1, time_t t0);
static int differ_by_repeat(t1, t0) const time_t t1; const time_t t0; { ... }
when time_t is of type 'short', say. (This is only a pedantic point as well, of course; nobody defines time_t to be that narrow.)
On Nov 6, 2007 9:25 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
"Jonathan Leffler" <jonathan.leffler@gmail.com> writes:
Is there actually a good reason not to write the whole library with ISO prototypes?
Not these days, no. Every practical C compiler supports prototypes nowadays. I think that stuff is now pedantic only, meant as illustration, to port back to ancient K&R compilers.
Thanks, Paul, for confirmation. Is there any virtue in changing the code to uniformily use prototype function definitions? If so, is there a protocol for making changes to the code? With whom should I be discussing the mechanics - you, Paul, or Mr Olson, or someone else? I know it is public domain and I can make modifications to my own copy, but I'd rather be more or less in sync with the official version for as long as I can. As long as we're being pedantic, it might be worth mentioning that the
current approach is not portable to arbitrary standard C platforms, since it assumes that time_t is at least as wide as int. C does not allow this:
static int differ_by_repeat(time_t t1, time_t t0);
static int differ_by_repeat(t1, t0) const time_t t1; const time_t t0; { ... }
when time_t is of type 'short', say. (This is only a pedantic point as well, of course; nobody defines time_t to be that narrow.)
Which illustrates several points - one being the prevalent use of const in the function definitions that doesn't necessarily appear in the prototype. The code also uses the register storage class a lot. My own code assumes that the compiler will handle register allocation at least as well as I do if the optimizer is used. Again, that could be partly historical (it used to matter; 20 years ago, I used register because on the machine I used, it mattered - and it also mattered whether malloc() was declared or not because it was a word-based machine, and the char pointer value for a given address was different from the int pointer for the same address). I wonder if there is a formal 'GNU indent' specification for how the code is formatted? Separately, addressing your 'short' issue - the bigger problem would be if time_t was a double or float, wouldn't it? (Hmmm; I'm not sure I follow all the importance of that - but as you say, the 'short' is purely pedantic since no machine uses short for time_t.) I'm not aware of any platform that uses float or double, either. There are plenty of (32-bit) Unix variants that use 32-bit signed integers for time_t; there are many 64-bit variants of Unix that use a 64-bit integer for time_t (counting plain seconds). I'm not aware of any C-based systems that use fancy alternatives like the Java milliseconds-since-the-epoch notation. I'm also not aware of any systems that provide picosecond resolution for sub-second times. I mention that mainly because one of the reasons I'm looking at the code at all is to consider whether to integrate it into a system that does provide such sub-second accuracy. -- Jonathan Leffler < jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
On Tue, 06 Nov 2007 09:47:15 -0800 Jonathan Leffler wrote:
static int differ_by_repeat(time_t t1, time_t t0);
static int differ_by_repeat(t1, t0) const time_t t1; const time_t t0; { ... }
Which illustrates several points - one being the prevalent use of const in the function definitions that doesn't necessarily appear in the prototype.
This is a feature ... top-level constness is the business of the definition, not the declaration.
participants (4)
-
Bradley White -
Erik van der Poel -
Jonathan Leffler -
Paul Eggert