Hi Bruno,
Bruno Haible wrote:
...
> Ad 1):
>> I suggest you declare those functions with the "nonnull" attribute.
>
> Good idea. I reported this to glibc:
> <http://sourceware.org/bugzilla/show_bug.cgi?id=11056>
That is welcome, but I was referring to the functions in progname.h:
set_program_name
set_program_name_and_installdir
> Ad 2):
> This is indeed a kernel problem: OpenBSD 4.0 returns with error code
> EFAULT if you pass NULL to execve or execv or execvp. Linux 2.6.25.20
Nor does rawhide's 2.6.32-0.56.rc8.git1.fc13.x86_64
> does not. Here's the draft for a report to a linux-kernel mailing list.
> Can someone please complete it for me? I am not used any more to rebuild
> and install modified Linux kernels.
>
> =========================== proposed linux-kernel report
> =======================
...
As you imply, it would be best to test the change.
Your changes do seem fine, but perhaps incomplete, since
you can make the same argument about the "envp" pointer.
> Ad 3):
> If you really want to do something that eases finding of such a bug in the
> parent process, then - rather than sweeping the bug under the carpet - provide
> an error message, like this.
That seems like a fine compromise.
My only reservation is that it causes an immediate abort,
whereas the program might otherwise have completed successfully,
i.e., if program_name were never used. Of course, I do realize
that this "fail early" aspect can be seen as a feature to help
detect and hence diagnose/repair the underlying cause in the parent.
Will you put this in gnulib?
Do you mean "the exec*ve* system call" or perhaps "an exec system call"?
> *** lib/progname.c.orig 2009-12-05 14:07:04.000000000 +0100
...
> + /* Sanity check. POSIX requires the invoking process to pass a non-NULL
> + argv[0]. */
> + if (argv0 == NULL)
> + {
> + fputs ("A NULL argv[0] was passed through the exec system call.\n",
> + stderr);
> + abort ();
> + }
