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

On 2011-01-25, at 19:57, Oliver Schmidt wrote:

> Hi,
>
>>> 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.
>
>> Yup. :-)
>
> Maybe there's a misunderstanding (?).

I am not sure here...

> It makes certainly sense to be
> able to inform the caller about errors. The only thing I'm saying is
> that there's no need for exec() to have a return value as the return
> value will *ALWAYS* be -1. If exec() returns to the caller than it is
> already evident that there was an error. When exec() returns the
> caller can directly go ahead and check errno. Again, technically
> there's no point in a return value that is a constant - is it?

"There shall be no return from a successful exec, because the calling  
process image is overlaid by the new process image."

So this is always valid, yet all the exec family functions do have a  
return value, even if they could do the same as you suggest. Now, I  
don't know why is that but:

"RETURN VALUES
      If any of the exec() functions returns, an error will have  
occurred.  The return value is -1, and the global
      variable errno will be set to indicate the error."

Therefore, while it technically doesn't make much sense, it seems to  
be THE way to go, unless we want to shave off couple of bits off the  
implementation. I'd go for the typical, described above way, unless  
cutting the ret value can really save non-negligible amount of mem on  
some systems. And since you wrote that you didn't have issue with the  
-1 constant return, there it is - I guess ;-)

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