[Top][All Lists]

[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

**a64l (and l64a) implementation is INCORRECT?**,
*Masaki Hasegawa* **<=**