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."