Hello! On Mon, Apr 09, 2007 at 08:43:25PM +0200, I wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x0105fc56 in __hurd_file_name_lookup (use_init_port=0x101aba8, > get_dtable_port=0x40000002, lookup=0, > file_name=0x40000002 <Address 0x40000002 out of bounds>, flags=0, > mode=1073741826, result=0x40000002) at hurdlookup.c:67 > 67 hurdlookup.c: No such file or directory. > in hurdlookup.c > (gdb) bt > #0 0x0105fc56 in __hurd_file_name_lookup (use_init_port=0x101aba8, > get_dtable_port=0x40000002, lookup=0, > file_name=0x40000002 <Address 0x40000002 out of bounds>, flags=0, > mode=1073741826, result=0x40000002) at hurdlookup.c:67 > #1 0x0112e517 in __access (file=0x40000002 <Address 0x40000002 out of > bounds>, type=4) at ../sysdeps/mach/hurd/access.c:112
> 72 if (!access(excludes_file, R_OK))
> (gdb) print excludes_file
> $1 = 0x0
> In glibc's `io/access.c' there is the following code:
>
> #v+
> int
> __access (file, type)
> const char *file;
> int type;
> {
> if (file == NULL || (type & ~(R_OK|W_OK|X_OK|F_OK)) != 0)
> {
> __set_errno (EINVAL);
> return -1;
> }
> [...]
> #v-
>
> (And the Linux code does the same thing, I guess.)
>
> However the Hurd's `sysdeps/mach/hurd/access.c' does not catch ``file ==
> NULL''. Should it do so? Reading
> <http://opengroup.org/onlinepubs/000095399/functions/access.html>
> doesn't tell me whether it should or not.
The same happens when passing NULL file names to `open' and a lot (if not
all) of their friends.
So, should instead `file_name_lookup' or `hurd_file_name_lookup' be made
robust enough to handle a NULL file name? (Fail with EINVAL?)
Regards,
Thomas
signature.asc
Description: Digital signature
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
