Re: (libf2c) libu77 struct timezone configuration fix

[Mumit Khan <khan at xraylith dot wisc dot edu>]

On Wed, 14 Apr 1999, Jeffrey A Law wrote:

>   > How is the standard autoconf test deficient, and why can't the test
>   > you need go inline in configure.in (as elsewhere), avoiding the extra
>   > complication of aclocal/acconfig?
> I wasn't aware there was a standard test for the timezone structure.  Is
> it possible that's a new standard test with autoconf-2.13?
> 
> As to not putting it in aclocal.m4, I've got no strong opinions on that. 

Dave, are you referring to the STRUCT_TIMEZONE test? If so, it's not what
you may infer from the name (it's to deal with struct tm and friends and
is a misnomer IMO).

 - Macro: AC_STRUCT_TIMEZONE
     Figure out how to get the current timezone.  If `struct tm' has a
     `tm_zone' member, define `HAVE_TM_ZONE'.  Otherwise, if the
     external array `tzname' is found, define `HAVE_TZNAME'.

Just to avoid confusion, here's my understanding of the various 
gettimeofday variants:
 
 - class 1: declares gettimeofday in the following way:
   
     int gettimeofday (struct timeval*, struct timezone*);
   
   and *does* use struct timezone to pass back timezone info. SunOS 4.1.x
   is one.

 - class 2: declares gettimeofday in the following way:

     int gettimeofday (struct timeval*, struct timezone*);

   but *does not* use struct timezone to pass back timezone info. This
   is a common one, and glibc2 is one such system. The 2nd arg should be 
   NULL for strict conformance.

 - class 3: declares gettimeofday in the following way:

     int gettimeofday (struct timeval*, void*);
   
   and contains a struct timezone as well. The 2nd arg should be NULL
   for strict conformance. HPUX 10.x is one such system.

  - class 4: declares gettimeofday in the following way:

     int gettimeofday (struct timeval*, void*);

   and does not declare a struct timezone. The 2nd arg should be NULL for 
   strict conformance. Interix is one such system, and I'm sure there are
   more.

Lovely, isn't it?

Regards,
Mumit