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

Hi Uz,

>> 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.

As already mentioned in this thread the process is most likely divided
in two phases:

- The preparation done before calling exit().
- The finalization after getting control from the startup code.

If something goes wrong in the first phase then everthing incl. errno
is still "there". If something goes wrong in the second phase there's
no way to return to the caller at all - be it with or without error
code. Anyway I've no issue with the "-1 constant" - it doesn't
increase the code size too much ;-)

I'm by the way somewhat more optimistic regarding error cases: For
example the classic "file not found" situation should be easily
handable in phase one.

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

Cool !

> Please let me know if there is anything wrong or missing. Maybe we want to
> allow a NULL pointer for cmdline?

Given the fact that this is most likely almost always the cases I'd
vote for yes.

> Or, should the prototype be only visible in
> cc65 mode?

I'm not enough of a standards guy to have an opinion on that.

> 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.

Thanks for the heads-up :-)

Regards,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.