bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

a64l (and l64a) implementation is INCORRECT?


From: Masaki Hasegawa
Subject: a64l (and l64a) implementation is INCORRECT?
Date: Tue, 23 Oct 2001 20:02:47 +0900

Dear Project members

Few years ago, I wrote a little program using a64l(3) on HP-UX machine.
And I have tried to port it to my Linux box that is running with glibc
2.2.2, I have found that glibc's a64l returns differnt value than HP's.
For example:
  on HP machine ... a64l("./") returns 64 , but
  on glibc      ... a64l("./") returns 1 .

According to the Open Group "The Single UNIX Specification, Version 2"
(http://www.opengroup.org/onlinepubs/007908799/xsh/a64l.html):
> The a64l() function takes a pointer to a radix-64 representation,
> in which the first digit is the least significant, and returns ...
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It seems that the glibc's implementation is INCORRECT.
I had to write following code to port my program appropriately.

#ifdef linux
#define a64l my_a64l
static long int a64l(char *s) {
        long int r = 0, i;
        char c;
        for (i = 0; i < 6 && (c = s[i]) != '\0'; i++) {
                int j;
                long int t = 0;
                if      (c <= '9') t = c - '.';
                else if (c <= 'Z') t = c - 'A' + 12;
                else               t = c - 'a' + 38;
                for (j = 1; j <= i; j++)
                        t *= 64;
                r += t;
        }
        return r;
}
#endif

I hope the a64l in glibc will be fixed like this.
How do you think about this problem?

--
Masaki Hasegawa <address@hidden>

  Numerical Prediction Division/ Japan Meteorological Agency



reply via email to

[Prev in Thread] Current Thread [Next in Thread]