Re: What is ``access (NULL, whatever)'' supposed to do?

[Thomas Schwinge]

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