This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: prepare for pre2
- To: drepper@cygnus.com
- Subject: Re: prepare for pre2
- From: Mark Kettenis <kettenis@wins.uva.nl>
- Date: Fri, 30 Apr 1999 18:26:51 +0200 (CEST)
- CC: libc-hacker@cygnus.com
- References: <r2676f82a3.fsf@happy.cygnus.com>
From: Ulrich Drepper <drepper@cygnus.com>
Date: 29 Apr 1999 15:55:48 -0700
If you have anything important for the pre2 release please tell me
now. I'll try to go through my big backlog on Saturday and try to
catch what was once sent. But don't hesitate sending the patches
again. If all is ok I'll make pre2 on Sunday or Monday.
It seems that there is a bug in sysdeps/i386/strchrnul.S. Make under
the Hurd reports something like :
execvp: true: Permission denied
The following program (sometimes) fails too:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
int
main (void)
{
char *argv[2];
argv[0] = strdup ("true");
argv[1] = NULL;
execvp (argv[0], argv);
perror ("execvp");
return EXIT_FAILURE;
}
The fact that it does it not always fails makes me suspect that it
depends on what random garbadge happens to be in the memory after the
strings. If you want to try to reproduce the problems, your best
chances are with trying to execute it with PATH=/bin.
Using the implementation in sysdeps/generic/strchrnul.c solves the
problems.
I couldn't get the test program above to fail under gdb, and the
execvp() call in make is hidden behind a fork(), which makes it very
hard to debug. The only information that I could extract is that the
return value of __strchrnul was wrong (too big). This result is that
execv is only called with the directory name, which of course fails.
I tried to find what is wrong by looking at the code itself, but my
knowledge of assembler is probably not good enough.
Mark
PS. The ChangeLog entry for these optimizations refers to
sysdeps/i386/bits/string.c and sysdeps/i386/i486/bits/string.c instead
of string.h.