<br><br><div class="gmail_quote">On Nov 6, 2007 9:25 AM, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div>"Jonathan Leffler" <<a href="mailto:jonathan.leffler@gmail.com" target="_blank">jonathan.leffler@gmail.com</a>> writes:<br><br>> Is there actually a good reason not to write the whole library with ISO

> prototypes? </div>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.

</blockquote><div> 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.

<br><br><br></div>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As long as we're being pedantic, it might be worth mentioning that the<br>current approach is not portable to arbitrary standard C platforms,

<br>since it assumes that time_t is at least as wide as int.  C does not<br>allow this:<br><br>static int differ_by_repeat(time_t t1, time_t t0);<br><br>static int<br>differ_by_repeat(t1, t0)<br>const time_t    t1;<br>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.) </blockquote></div> 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.

<br clear="all"><br>-- <br>Jonathan Leffler <

<a href="mailto:jonathan.leffler@gmail.com" target="_blank">jonathan.leffler@gmail.com</a>>  #include <disclaimer.h><br>Guardian of DBD::Informix - v2007.0914 - <a href="http://dbi.perl.org" target="_blank">http://dbi.perl.org

</a><br>"Blessed are we who can laugh at ourselves, for we shall never cease to be amused."