[cc65] Calling another program: exec() ?

From: Oliver Schmidt <ol.sc1web.de>
Date: 2011-01-24 12:46:43
Hi,

I guess several cc65 targets allow one way or another to replace the
currently running program with another one without manual user
intervention. At least the Apple II does and there's a project
(A2-Command) asking for that functionality so I'm about to add it to
the Apple II C library.

My question is if you think it is appropriate to call that function
execl() / execv() or if a proprietary name would be preferable.
Reading the standards there are some things which on cc65 targets
wouldn't behave exactly as described:
http://pubs.opengroup.org/onlinepubs/009695399/functions/environ.html

Here's an example if the things I'm refering to:

"File descriptors open in the calling process image shall remain open
in the new process image, except for those whose close-on- exec flag
FD_CLOEXEC is set. For those file descriptors that remain open, all
attributes of the open file description remain unchanged. For any file
descriptor that is closed for this reason, file locks are removed as a
result of the close as described in close(). Locks that are not
removed by closing of file descriptors remain unchanged.

If file descriptors 0, 1, and 2 would otherwise be closed after a
successful call to one of the exec family of functions, and the new
process image file has the set-user-ID or set-group-ID file mode bits
set, [XSI]   and the ST_NOSUID bit is not set for the file system
containing the new process image file,  implementations may open an
unspecified file for each of these file descriptors in the new process
image."

I don't see keeping any file descriptors open on cc65 targets - do you?

And finally there's an aspect of the execl() / execv() in the
standards that causes me trouble: As far as I understand and according
to the following bug report "atexit-functions" aren't called on
execl() / execv():
http://sourceware.org/bugzilla/show_bug.cgi?id=6982

Does this really make sense? But at least the cc65 desctructors need
to be called. Otherwise there would be i.e. dengling interrupt vectors
pointing to nowhere - wouldn't they?

Any thoughts?

Thanks in advance,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Mon Jan 24 12:46:57 2011

This archive was generated by hypermail 2.1.8 : 2011-01-24 12:47:04 CET