This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] AmigaOS 4 port contribution
"Zack Weinberg" <zack@codesourcery.com> writes:
> 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.
Such code is in pex-amigaos.c in my patch.
> 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.
That depends on the purpose of the design. The single string is
intended for shell usage, where what you type is actually a string.
For the normal windowed evironment, you would instead pass a WBStartup
structure, which has a vector of WBArgs. These are not plain strings
though, but references to DiskObjects (files) which may have further
parameterization associated with them in the form of key/value pairs.
> 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.
You might just as well say that this is a catastrophic design flaw in
C. If main had been defined to take a struct WBStartup pointer
instead of a vector of strings, then the startup logic would not have
had to do anything.
It's a mismatch between the designs, not a design fault in either C or
AmigaOS in themselves. Remember that UNIX and C were developed
together, so it is not surprising that their designs fit each other
well. For other systems and languages, there can be less of match.
This does not mean that these systems or languages are flawed.
Anyway, this all seems a bit off topic since the design of both C and
AmigaOS are fixed in this regard, and therefore not something which
can be changed by my patch.
> 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.
Yes, but there were many other change requests to the patch to
consider as well, and time is running short. The -pipe thing does not
introduce a new #ifdef to gcc.c, it just extends an existing one, so
there is not very much to gain in the respect of minimizing change to
the gcc directory in this particular case.
> 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.
Hm. Well, collect2 only needs a pipe as the output of the process,
and in this case there should be no problem to fake it with a file if
necessary. collect_execute already has code to send output of the
command to a file, so that much should be possible to deliver at
least.
// Marcus