Re: [cc65] Calling another program: exec() ?

Hi!

On Tue, Jan 25, 2011 at 12:12:30PM +0100, Oliver Schmidt wrote:
> > Having an error code allows an "explanation" of the failure.
>
> The execl() function and friends just return -1 and set errno for more
> details. I presumed that exec() would behave the same...

As I've found out, when writing the funcref entry (see below), returning an
error in errno will probably not work in most cases, since when we load the
new program, the old one has already terminated, files have been closed and
the destructors have been run. It may be possible to return on some errors, so
I think the error code is still a good idea and not too much overhead.

> I see the argument. So it's unistd.h.

Yep. I've already added the prototype and added an entry to funcref.sgml:

------------------------------------------------------------------------------
3.58 exec

    Function
        Execute a program file.

    Header
        unistd.h

    Declaration
        int __fastcall__ exec (const char* progname, const char* cmdline);

    Description
        exec replaces the currently running program by a new one. Calling
        exec() is identical to calling exit(), then loading and starting the
        program named in the first argument, passing the command line
        specified as second argument. On success, the function does not
        return. On failure, -1 is returned and errno contains an error code.

    Limits

        * The function is only available as fastcall function, so it may only
          be used in presence of a prototype.
        * On most platforms, the function needs to copy a small stub loader to
          some memory area outside the program space. This may collide with
          other programs. See the platform specific docs on this.
        * Because it is necessary to terminate the running program before the
          memory can be reused to load the new one, there is a high chance
          that the function may not be able to return on errors.
        * The command line is passed to the new program in the same way as
          cc65 programs expect the command line. If the new program is not a
          cc65 generated program, it may not be able to read it.

    Availability
        cc65

    See also
        exit

    Example
        None.
------------------------------------------------------------------------------

Please let me know if there is anything wrong or missing. Maybe we want to
allow a NULL pointer for cmdline? Or, should the prototype be only visible in
cc65 mode?

Please note that the current development version may not work correctly
because of incomplete changes in the object file format. Nightly builds are
currently disabled for this reason.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.