[tz] dead code in zic

[Arthur David Olson]

> ...if the code is a no-op on all 32 bit platforms it should probably be
improved!

While the code in question can surely be improved, it wasn't/isn't a no-op
on
systems where both time_t's and long's were/are 32-bit entities.

> This is yet another case where the code mis-uses variable sized types
> (long which is different on ILP32 and LP64) and could be improved.

The code in question dates back to when "long" was the longest integer type
available with all compilers ("long long" was not universal then).

        @dashdashado


On Tue, Mar 5, 2013 at 9:47 PM, Christos Zoulas <christos at zoulas.com> wrote:

> On Mar 5,  6:07pm, eggert at cs.ucla.edu (Paul Eggert) wrote:
> -- Subject: Re: [tz] dead code in zic
>
> | I suggest changing change the compiler options
> | to suppress the warnings, or at least to make the warnings
> | not cause compilation to fail.  There's nothing invalid
> | about a comparison that happens to always be true on the VAX.
> | Comparisons like that are normal and should be expected in
> | code that tries to be portable among a wide variety of
> | hardware platforms.
>
> Yes, and ILP32 is a portable and popular platform (still).  This is
> not VAX specific.  As I mentioned before if you change the const
> variable declaration to a #define, you'll get the warning in all
> gcc 32 bit platforms (or if you use a gcc circa 4.1 which had code
> to do the constant folding more aggressively). In simple terms, if
> the code is a no-op on all 32 bit platforms it should probably be
> improved!
>
> I know how to suppress warnings (with casts for example), and how
> to not compile with -Werror.  What I am asking here, is if dayoff
> is mistyped (long instead of zic_t) and 'long oadd(long, long)'
> should be 'zic_t oadd(zic_t, long)'.
>
> This is yet another case where the code mis-uses variable sized types
> (long which is different on ILP32 and LP64) and could be improved.
>
> christos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20130305/02e9555f/attachment.html