Re: library bug?

[Siggy Brentrup <bsb@beck.westfalen.de>]

>>>>> "Alan" == Alan Eugene Davis <adavis@kuentos.guam.net> writes:

    Alan> After successfully compiling ELF binaries for PROJ.4 (map projections
    Alan> conversion package), I followed these instructions to test for
    Alan> "braindead" libraries, which failed.  I think this may be of some
    Alan> interest to the maintainers of the libraries.  I must admit, I haven't
    Alan> a clue which library is involved.  

O.K. here's the libc (and libm) maintainer :)

    >> Check /usr/include/math.h for prototype of hypot.  If missing it is
    >> probably not in libm.a and it is necessary to use supplied version.

    Alan> I think hypot was present.
    Alan>   ^^^^^

You are right, I know for sure :-)

    >> 
    >> make install HYPOT='$L(hypot.o)'
    >> or
    >> make install HYPOT='$L(hypot.o)' STRTOD='$L(strtod.o)'

    >> 
    >> To check for brain damaged versions of strtod try the following after
    >> using the local system's version (default):
    >> 
    >> proj +proj=poly +ellps=clrk66 +no_defs <<EOF

Wow, use brain damaged (read non POSIX compliant) flags to test for non-ANSI strtod ?

    >> 3.5 33.25
    >> 3d30 33d15
    >> EOF
    >> 
    >> Both geographic coordinates should produce the same cartesian result.
    >> If not, then it is almost a certainty that libc.a has a version modified
    >> to accept d | D as an alternative to e | E.  This "extension" to ANSI
    >> specifications causes untold grief.  Use the ANSI compliant GNU version
    >> included.


    Alan> The values I got were:

    Alan>           326186.98    3685744.37
    Alan>           326725.05    3667246.41 

    Alan> Close, but no cigar.

What results did you get with the included ANSI compliant GNU version?
I suspect there are some numeric problems. From the top of my head,
these geodetic conversions are numerically bad behaved.

    Alan> I am running GCC 2.7.2 
    Alan>              libc5-dev   5.2.18-1
    Alan>              libc5       5.2.18-1 

    Alan> Also installed on the system is  libc4 4.6.27-11, but I don't have the
    Alan> a.out compiler.

    Alan> I haven't been able to quite comprehend the remedy, but a
    Alan> local "ANSI compliant GNU version" of the offending function is
    Alan> included with the source code.

The source file strtol.c carries a GNU copyright notice, if this
doesn't convince you, here is a small test program, proving that the
differences you are complaining about, are not strtod's fault.

-------------------------- it.c ---------------------------
#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int
main (int argc, char **argv)
{
  char buf[128];

  while ( scanf("%s", buf) == 1 )
	printf("hypot(0.0, strtod(\"%s\")) == %g\n",
		   buf, hypot(0.0, strtod(buf,NULL)));
  return 0;
}
-----------------------------------------------------------
bora:~/tmp: gcc -Wall -O2 -lm -o it it.c
bora:~/tmp: it <<EOF
12.34 12.34e56 12.34d56
EOF
strtod("12.34") == 12.34
strtod("12.34e56") == 1.234e+57
strtod("12.34d56") == 12.34
bora:~/tmp: ldd it
	libm.so.5 => /lib/libm.so.5.0.5
	libc.so.5 => /lib/libc.so.5.2.18


BTW: This is for the implemnetor of proj: there is a nice GNU tool
     called autoconf, you can use it to create a confguire script that
     finds out if the system your program is compiled on is "brain
     damaged"<grrr>, better yet you can use it to write portable code.

Siggy

-- 
mailto:bsb@uni-muenster.de           //      programmer/admin for hire
       bsb@beck.westfalen.de         \\  Opinions are strictly my own,
voice: +49-251-8619-99                \\      everything else is GPLed
                                 http://www.westfalen.de/private/beck/