tzcode2007h.tar.gz - Functions defined with prototypes and C99 features?

[Jonathan Leffler]

On Nov 6, 2007 9:25 AM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> "Jonathan Leffler" <jonathan.leffler at 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 at 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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20071106/41375df9/attachment-0001.html