Re: [PATCH] AmigaOS 4 port contribution

["Zack Weinberg" <zack at codesourcery dot com>]

Marcus Comstedt <marcus@mc.pp.se> writes:

> "Zack Weinberg" <zack@codesourcery.com> writes:
>
>> These changes are problematic on several grounds.
>> 
>> 1) Most critically important, you may not use popen.  You must use
>>    lower-level APIs that take argument *vectors* and do not invoke
>>    an intermediary shell.  If AmigaOS provides no way to do this,
>>    then AmigaOS's kernel API is *broken* and must be fixed.
>
> Well, you can try sending a kernel patch to Hyperion, but I don't
> think it will get in 4.0...  AmigaOS commandlines are strings, not
> vectors.   It has always been that way, and it will probably stay that
> way from some time yet.

I was afraid of that.  In that case we're going to need you to write
code which accepts an argument vector and carefully translates it to
a string, quoting each entry as necessary so that arbitrary characters
(other than NUL) are correctly preserved all the way to the second
argument to main() in the child process.  See pex-win32.c in the patch
I referred you to, for an example.

> And I assume you also know that there is a pexecute implementation for
> MSDOS which does the same thing?  If all systems are required to
> function like UNIX, then what's the point of pexecute?

I didn't say that all systems had to have exactly the same process
creation API.  I said that a process creation API that takes a single
string is a catastrophic design flaw.  I'm aware that this is a very
common design flaw; that doesn't make it not a flaw.

The reason it's a catastrophic design flaw is, any such API will need
to have a mechanism that translates from the single string to the
argument vector that's passed to main() in the child process.  (This
generally happens in the C runtime's startup logic.)  If this
mechanism is not clever enough, it will be impossible to pass
arbitrary strings - in particular, arbitrary file names - down.  If
it's too clever, it is liable to be poorly documented and buggy.  The
bugs often constitute security holes, ranging all the way from "you
can get the child process to access the wrong file" to "you can trick
the parent process into executing a program of your choice instead of
the one it wanted."

Don't take my word for it; write the quoting logic and see.

>> 2) You should not need to disable -pipe just because the OS doesn't
>>    have pipes.  Look at the way this is handled under DJGPP.
>
> The OS does have pipes.  So it possible to have -pipe, once support
> for it is added to pexecute.  But that can come later.  No need to
> make the patch even bigger than it already is.

We would rather not have transitional states like that.  Besides, if
you do a full pexecute implementation now, the changes required in the
gcc directory will be smaller.

>>    For collect2, see the API revision I tried to institute way back in
>>    January and the commentary it drew.  I do not have time to make this
>>    patch acceptable myself, but I would be happy to work with you to
>>    get it there.
>>    [http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02331.html]
>
> Hah, some of that commentary suggests that popen() should be used.  :)
>
> Well, with your patch my job would certainly be a bit easier.  Was
> there any consensus on exactly why it was bad?

It was felt that the API promised what it could not necessarily
deliver (namely pipes).  I think this is mistaken, but I'd be fine
with changing it to make the situation clearer.

zw