tzcode standard C patch

Martin Smoot msmoot at nssolutions.com
Thu Jul 27 21:24:24 UTC 2000


"Olson, Arthur David (NCI)" wrote:
> 
>         ...You shouldn't need that patch; all you
> > should need to do is to compile with -DHAVE_STRERROR=1.  That being
> > said, I think HAVE_STRERROR should default to 1 these days; strerror
> > has been in the C standard for more than a decade and I no longer have
> > access to any hosts that lack strerror.
> >
> > Here's a proposed patch...
> >
> Another approach would be to just drop the two pieces of code that are
> conditioned on HAVE_STRERROR from zic.c.
> 
>                                 --ado

I have only recently signed up on this list (about 2.5 weeks ago).......


I would agree that changing the default for HAVE_STRERROR is a good idea
(we set it in our make file from the beginning) but would recommend
against removing the HAVE_STRERROR code from zic.c at this time.  I
would suggest doing one or both of the following instead:

1.  add a #warning line within that block of code suggesting that having
HAVE_STRERROR set to zero may not be needed.

2.  put the strerror routine in a new source file (possibly not normally
compiled).

It always seems that when a routine is removed, somebody suddenly needs
it so keeping it around for a while may be a good idea.



After some period of time (say 6 months), it should be safe to remove
the routine from the normal distribution (unless a lot of users really
need the routine).



Something else to consider:

Depending on compatibility for various operating system routines and
commands may not be a good idea.  I have modified zic.c to output the
data as a set of include files formatted so they could be compiled into
our code.  When we changed from using Solaris to Linux for our
development environment, the "sort" step for these include files in our
build failed to work as we expected it to - the data was not in the same
order as it was before!!  we tried changing the sort parameters to make
it work but finally decided to write our own sort which did do exactly
what we wanted it to do using both Solaris and Linux (and never figured
out why the sort would not work - was not worth the effort to find out
once we had our fix).

If this code depends on something happening a very specific way (like my
sort check did), it may be safer to include the appropriate "guaranteed
correct" code as part of the package rather then depend on whatever
system the code is built on to do it that way.

-- 
Martin Smoot
Network Storage Solutions
703-834-2242
msmoot at nssolutions.com         www.nssolutions.com



More information about the tz mailing list