Bug#416928: libc6: off-by-one bug in strxfrm()
Package: libc6
Version: 2.3.6.ds1-13
Severity: normal
The result of strxfrm() varies depending on the length of the destination
buffer. In particular, in the pl_PL.UTF8 locale, strxfrm(buf, "a", i)
returns 6 for i <= 6, and 5 for i > 6 (and the string placed in the
destination buffer does, indeed, have the length of 5). This mismatch is
probably unintended. It is also a violation of the C standard, which states:
"The strxfrm function returns the length of the transformed
string (not including the terminating null character)."
Steps to reproduce:
$ cat foo.c
#include
#include
#include
int
main(void)
{
char buf[42];
size_t i;
printf("%s\n", setlocale(LC_COLLATE, "pl_PL.UTF8"));
for (i = 0; i <= 9; ++i)
{
char *p;
memset(buf, '\0', sizeof(buf));
printf("%zd: %zd:", i, strxfrm(buf, "a", i));
for (p = buf; *p; ++p)
printf(" %02x", (int)*p);
printf("\n");
}
return 0;
}
$ gcc foo.c && ./a.out
pl_PL.UTF8
0: 6:
1: 6:
2: 6: 0c 01
3: 6: 0c 01
4: 6: 0c 01 08 01
5: 6: 0c 01 08 01
6: 6: 0c 01 08 01 02 01
7: 5: 0c 01 08 01 02
8: 5: 0c 01 08 01 02
9: 5: 0c 01 08 01 02
$
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=C, LC_CTYPE=pl_PL.UTF8 (charmap=UTF-8)
Versions of packages libc6 depends on:
ii tzdata2007b-1Time Zone and Daylight Saving Time
libc6 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412569: libc6: zdump -v segfaults
So on amd64, with 2.3.2.ds1-22sarge4 I get: intrepid:~$ zdump -v /usr/share/zoneinfo/UTC /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL intrepid:~$ zdump --version @(#)zdump.c 7.64 Upgrading to 2.3.2.ds1-22sarge5 I get: intrepid:~$ zdump -v /usr/share/zoneinfo/UTC Segmentation fault intrepid:~$ zdump --version zdump: invalid option -- - zdump: usage is zdump [ -v ] [ -c cutoff ] zonename ... I think it broke on 64 bit arches. With 2.3.6.ds1-13 (unstable) I still get: intrepid:~$ zdump -v /usr/share/zoneinfo/UTC /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL intrepid:~$ zdump --version @(#)zdump.c 7.66 On i386 I get: intrepid:~$ zdump -v /usr/share/zoneinfo/UTC /etc/localtime Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:45:52 1901 UTC isdst=0 gmtoff=0 /etc/localtime Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:45:52 1901 UTC isdst=0 gmtoff=0 /etc/localtime Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 UTC isdst=0 gmtoff=0 /etc/localtime Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 UTC isdst=0 gmtoff=0 On amd64, it never seems to show 1901 / 2038 properly. If I use a different timezone, and not using 2.3.2.ds1-22sarge5 the first 2 and last lines still look the same, but the rest between them look normal. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
