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