[Bug 842258] Re: ARM strchr fails to convert c to char
Launchpad Bug Tracker
842258 at bugs.launchpad.net
Fri Sep 9 14:05:23 UTC 2011
This bug was fixed in the package eglibc - 2.13-20ubuntu1
---------------
eglibc (2.13-20ubuntu1) oneiric; urgency=low
[ Colin Watson ]
* Revert change from 2.13-17ubuntu2 now that data.tar.xz support is
deployed in Launchpad. Add Pre-Depends: dpkg (>= 1.15.6) to affected
packages.
[ Dr. David Alan Gilbert ]
* ARM strchr: mask r1 to char (LP: #842258)
[ Matthias Klose ]
* Merge with Debian (r4955).
eglibc (2.13-20) unstable; urgency=low
* debian/debhelper.in/libc.preinst: call /bin/mv with --version so
that it doesn't return an error. Closes: #640872.
eglibc (2.13-19) unstable; urgency=low
[ Aurelien Jarno ]
* Change libc_rtlddir to /lib on s390x.
* Add debian/patches/submitted-glob_h-ifdef.diff to fix an undefined
preprocessor symbol in some rare conditions. Closes: #639213.
* debian/sysdeps/sparc64.mk: re-enable multiarch similarly to what
has been done on sparc.
* debian/control.in/libc: remove Breaks: on perl. Closes: #640300.
* debian/patches/localedata/locale-C.diff: Don't include ISO14651
collation rules in C.UTF-8 locale.
* Update debian/patches/svn-updates to revision 15228:
- Drop debian/patches/any/cvs-dl-deps.diff (merged upstream).
- Drop debian/patches/arm/cvs-align-constant-pool.diff (merged upstream).
* debian/debhelper.in/libc.preinst: get the dynamic linker from /bin/mv
instead of /bin/true. Closes: #640753.
[ Jeremie Koenig ]
* New patches to improve the signal code on Hurd:
patches/hurd-i386/submitted-hurdsig-fixes.diff,
patches/hurd-i386/submitted-hurdsig-global-dispositions.diff,
patches/hurd-i386/submitted-hurdsig-SA_SIGINFO.diff,
patches/hurd-i386/submitted-hurdsig-fixes-2.diff.
* Update testsuite accordingly.
* Remove patches/hurd-i386/submitted-PTRACE_CONTINUE.diff, now covered by
submitted-hurdsig-fixes.diff.
* libc0.3.symbols.hurd-i386: Add version for global-disposition functions.
[ Samuel Thibault ]
* Add patches/hurd-i386/submitted-libc_stack_end.diff to fix ruby1.9.1 stack
detection.
* Add patches/hurd-i386/submitted-ttyname_ERANGE.diff to fix ttyname error
value.
* Add patches/hurd-i386/submitted-DEV_BSIZE.diff to add DEV_BSIZE.
[ Petr Salinger ]
* kfreebsd/local-sysdeps.diff: update to revision 3697 (from glibc-bsd).
- fixes ld.so location used inside ldd on kfreebsd-amd64. Closes: #640156.
- wrap faccessat() X_OK testing for superuser. Closes: #640325.
eglibc (2.13-18) unstable; urgency=low
* On s390x the PI is /lib/ld64.so.1, so we don't need to move
ld64.so.1 from /lib to /lib64.
-- Matthias Klose <doko at ubuntu.com> Fri, 09 Sep 2011 13:44:41 +0200
** Changed in: eglibc (Ubuntu)
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/842258
Title:
ARM strchr fails to convert c to char
Status in “eglibc” package in Ubuntu:
Fix Released
Bug description:
C99 says:
"The strchr function locates the first occurrence of c (converted to
a char) in the string pointed to by s."
The current ARM strchr implementation in eglibc (2.13-17ubuntu2)
starts off like this:
ldrb r2,[r0],#1
cmp r2,r1
This loads a byte from the address pointed to by the first argument
(s), zero-extends it to 32 bits, and then compares it directly against
the second argument (c). If c is negative, this fails.
I think that this function should first convert c to a char, e.g. by
zeroing the top 24 bits. char is unsigned on this platform, so (char)
-1 == (int) 255.
Here's a test program. By my reading of C99, it should return 0. On
Ubuntu 11.10 armel, it currently returns 1. (This is the root cause
of bug 791274, although it's easily worked around by passing the
anyway less obtuse value of 255 rather than -1.)
#include <string.h>
int main(int argc, char **argv) {
const char *s = "\xff";
if (strchr (s, -1) == s)
return 0;
else
return 1;
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/842258/+subscriptions
More information about the foundations-bugs
mailing list