"exec" procedures don't handle the optional parameters unbounded situation?

"exec" procedures don't handle the optional parameters unbounded situation?

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

I found "exec" serial procedures didn't check the unbounded optional
parameters.
(execlp "ls")  ==> segment fault
(execlp "ls" "") ==> success

-------------------------------cut----------------------
 ......
  char *exec_file;
  char **exec_argv;

  scm_dynwind_begin (0);

  exec_file = scm_to_locale_string (filename);
  scm_dynwind_free (exec_file);

  exec_argv = scm_i_allocate_string_pointers (args);

  execvp (exec_file,
#ifdef __MINGW32__
          /* extra "const" in mingw formals, provokes warning from gcc */
          (const char * const *)
#endif
          exec_argv);
  SCM_SYSERROR;
......
----------------------------end cut--------------

====================================================
And I think the optional argv should be checked if it's unbounded.

-----------cut---------------
   ......
   char *exec_file;
   char **exec_argv;
+ char *no[] = {"", NULL};

   scm_dynwind_begin (0);

   exec_file = scm_to_locale_string (filename);
   scm_dynwind_free (exec_file);

+ exec_argv = SCM_UNBNDP (args) ? no : scm_i_allocate_string_pointers
(args);

   execvp (exec_file,
#ifdef __MINGW32__
          /* extra "const" in mingw formals, provokes warning from gcc */
          (const char * const *)
#endif
          exec_argv);
   SCM_SYSERROR;
...............
-----------end cut----------

I do make this change in my guile src, but it seems no effect.
Or the original implementation is accepted? Since all the "exec" serial
procedures' implementation don't check the unbounded optional parameters.

[-- Attachment #2: Type: text/html, Size: 2422 bytes --]

Re: "exec" procedures don't handle the optional parameters unbounded situation?

[Ludovic Courtès]

Hi!

Sorry for the late reply.

Nala Ginrut <nalaginrut@gmail.com> skribis:

> I found "exec" serial procedures didn't check the unbounded optional
> parameters.
> (execlp "ls")  ==> segment fault

What you’re seeing here is SIGABRT, not SIGSEGV, preceded by the message:

  A NULL argv[0] was passed through an exec system call.

That message comes from Gnulib’s ‘set_program_name’ [0], which is used
by all GNU Coreutils program, and which aborts when argv[0] is NULL.

Thanks,
Ludo’.

[0] http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/progname.c#n53

Re: "exec" procedures don't handle the optional parameters unbounded situation?

[Nala Ginrut]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

hi Ludo, thanks for reply.
I realized that it's not SIGSEGV ,it's an "abort" while argv[0] is NULL.
Now the problem is  "can we avoid to pass void string to exec proc
explicitly"?
Since Guile provides flexible optional arguments handling, why we can not
do this:
let (execlp "ls")  equal to (execlp "ls" "") if the second argument is
unbounded?

On Fri, Dec 16, 2011 at 3:19 AM, Ludovic Courtès <ludo@gnu.org> wrote:

> Hi!
>
> Sorry for the late reply.
>
> Nala Ginrut <nalaginrut@gmail.com> skribis:
>
> > I found "exec" serial procedures didn't check the unbounded optional
> > parameters.
> > (execlp "ls")  ==> segment fault
>
> What you’re seeing here is SIGABRT, not SIGSEGV, preceded by the message:
>
>  A NULL argv[0] was passed through an exec system call.
>
> That message comes from Gnulib’s ‘set_program_name’ [0], which is used
> by all GNU Coreutils program, and which aborts when argv[0] is NULL.
>
> Thanks,
> Ludo’.
>
> [0] http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/progname.c#n53
>
>
>

[-- Attachment #2: Type: text/html, Size: 1654 bytes --]

Re: "exec" procedures don't handle the optional parameters unbounded situation?

[Ludovic Courtès]

Hello!

Nala Ginrut <nalaginrut@gmail.com> skribis:

> Since Guile provides flexible optional arguments handling, why we can not
> do this:
> let (execlp "ls")  equal to (execlp "ls" "") if the second argument is
> unbounded?

Because it would differ from what the underlying system call allows, and
would also be an incompatible change.

Thanks,
Ludo’.

Re: "exec" procedures don't handle the optional parameters unbounded situation?

[David Kastrup]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello!
>
> Nala Ginrut <nalaginrut@gmail.com> skribis:
>
>> Since Guile provides flexible optional arguments handling, why we can not
>> do this:
>> let (execlp "ls")  equal to (execlp "ls" "") if the second argument is
>> unbounded?
>
> Because it would differ from what the underlying system call allows, and
> would also be an incompatible change.

Incompatible?  You really think there are programs relying on this being
an error?  I agree that a system call wrapper should not be too clever,
but compatibility is hardly a concern here.

-- 
David Kastrup

Re: "exec" procedures don't handle the optional parameters unbounded situation?

[Andy Wingo]

> On Fri, Dec 16, 2011 at 3:19 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>
>     Nala Ginrut <nalaginrut@gmail.com> skribis:
>    
>     > I found "exec" serial procedures didn't check the unbounded optional
>     > parameters.
>     > (execlp "ls")  ==> segment fault
>    
>     What you’re seeing here is SIGABRT, not SIGSEGV, preceded by the message:
>    
>      A NULL argv[0] was passed through an exec system call.
>    
>     That message comes from Gnulib’s ‘set_program_name’ [0], which is used
>     by all GNU Coreutils program, and which aborts when argv[0] is NULL.

I had thought at first that this SIGABRT / SIGSEGV came from Guile
itself, in which case this would be a bug, but as it comes from `ls', I
also think that the current code is the correct code.

For what it's worth :-)

Andy
-- 
http://wingolog.org/