<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
<br>> prototypes?<br><br></div>Not these days, no. Every practical C compiler supports prototypes<br>nowadays. I think that stuff is now pedantic only, meant as<br>illustration, to port back to ancient K&R compilers.
<br></blockquote><div><br>Thanks, Paul, for confirmation.<br><br>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;
<br>{ ... }<br><br>when time_t is of type 'short', say. (This is only a pedantic point<br>as well, of course; nobody defines time_t to be that narrow.)<br></blockquote></div><br>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?
<br><br>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.
<br><br>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."