"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@nssolutions.com www.nssolutions.com