[Asterisk-Dev] Re: ast_localtime() weird interface.

[Tilghman Lesher]

On Wednesday 12 October 2005 03:17, Luigi Rizzo wrote:
> On Wed, Oct 12, 2005 at 07:15:37AM +0000, Tony Mountifield wrote:
> > In article <20051011233741.B19609 at xorpc.icir.org>,
> >
> > Luigi Rizzo <rizzo at icir.org> wrote:
> > > hi,
> > > i am trying to compile asterisk-current with -Werror to clean
> > > up compile errors, and amomg other things i hit a number of
> > > inconsistencies on the first argument of ast_localtime() (this
> > > on FreeBSD-6, but the problem may exist elsewhere depending on
> > > how time_t is defined).
>
> ...
>
> > > and i'd like to change it, so that it is much easier to deal
> > > with the different definitions of time_t on the various
> > > platforms.
> >
> > Since everyone who is familiar with the localtime functions would
> > be used to the existing case, I think such a change would be less
> > desirable.
> >
> > What kind of problems are you encountering in dealing with the
> > different definitions of time_t?
>
> the problem is that depending on the platform, time_t is
> some variant of integer types, and a zillion places in say.c
> calls ast_localtime() using &foo.tv_sec as a first argument
> where foo is of type struct timeval.
>
> The two types happen to differ on FreeBSD-6, as may be the case on
> many other OS where system headers try to adapt to 64-bit
> values for some types but one reason or another struct timeval and
> time_t are not in sync.

That sounds like a call for you to fix FreeBSD.

> Now, if we pass the argument by value (which is all we need)
> the compiler can do the required cast automatically.
> There is no other safe workaround because if the types differ
> even an explicit cast won't help.

Yep, and at some point in about 30 years, we're going to need to
change time to a 64bit value.  Wouldn't it be wise to do that NOW,
when you're going through the pains of 64-bit type conversion?

And then you won't need to change ast_localtime(), and it can remain
just like localtime() and localtime_r().

-- 
Tilghman