Subject: RE: mingw32 - noncygwin32 gcc - libwinserve.a
From: [email-masked] (Colin Peters)

17 Oct 1997 03:54:54 -0700
Message-ID: <01BCDB11.0B047620.cygnus.gnu-win32@gbird0>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: "Pedro A. Aranda Gutiirrez" <[email-masked]>,
        "'Jan-Jaap van der Heijden'"
	 <[email-masked]>
Cc: "'GNU-Win32'" <[email-masked]>

Jan-Jaap van der Heijden[SMTP:[email-masked]] wrote:
>On Wed, 15 Oct 1997, Pedro A. Aranda Gutiirrez wrote:
>
>> Earnie Boyd wrote:
>> > I have found a bug in the mingw32 version of gcc though:
>> > If you have spaces in a -Dmacro='"this that something"' gcc comes back
[snip: an error]
>> 
>> I would say that it is ***AND*** it isn't a bug in gcc. It's the
>> behaviour of manyGNU tools once recompiled to use CRTDLL.DLL <snif>. It
>> has something to do
>> with the way we pass arguments to the spawn...() functions. As far as I
[snip]
>
>This is supposed to be fixed in the test "prerelease" which is in
>ftp://agnes.dida.physik.uni-essen.de/home/janjaap/private/mingw32/
>
>To quote the source:
>
>/* This is a kludge to get around the Microsoft C spawn functions'
>   propensity to remove the outermost set of double quotes from all
>   arguments.  */

It's only partially spawn's fault. Spawn doesn't do anything to
quotes in args, or slashes, backslashes, or anything else.
Unfortunately what we have here (if I am correct) is a basic
limitation of the OS. Arguments are not passed between processes
as a block of null-terminated strings, but as a single command
line string (curse the programmer who made this coding
decision). Spawnv can do nothing but attempt to create a
reasonable command line from the argv block, and what it does is
concatinate all the members of the block together, with a single
space between each.

Then the mingw32 startup code calls _GetMainArgs, which is
implemented in crtdll, to break up the command line into tokens
and put them in an __argv block. Of course, if any of the args
passed to spawnv contained spaces then the tokenization will
not be the same.

In order to allow args with spaces _GetMainArgs allows args to
be quoted, and quotes to be escaped with backslashes, and
backslashes in front of quotes to be escaped with backslashes.
To get exactly the same thing that you mean to pass with spawn
in the argv array of a mingw32 program (or probably any MS
program-- confirmations for VC++ behavior anyone?) you have to
follow these rules (I think):

 - Double all backslashes preceeding a quote (including sets
   of multiple backslashes e.g. \\" -> \\\\", if you don't do
   this \\" -> \\\" and after the next step \\\\", and that
   ends up as \\ in the called program, with the quote dropped).
   Do not double backslashes that are not in front of a quote.
 - Put a backslash in front of all quotes within an arg.
 - Put quotes around all args containing whitespace.

This is ugly ugly ugly... and it's also one of the things I
wish MS would break compatibility to fix. The shell or calling
process should tokenize the args, not the new process, and
pass them as a block, like UNIX does (if I understand correctly).

Still, I am not yet decided whether, in the context of mingw32,
this is a problem that should be fixed at all. Basically my
argument is:

 1) Most of the time this does not cause problems, and many of
    those problems can be solved by properly quoting args on
    the command line.

 2) Mingw32 makes a best effort to be compatible, but it is,
    essentially, a way of morphing GCC into a Win32 complier.
    Offering total UNIX compatibility is much better done with
    a completely independent C run time-- Mingw32 cannot hope
    to implement fork, signals, etc. in a UNIX compatible way
    without completely abandoning any pretense of "minimalism".

It's possible that spawn wrappers, like the dirent
implementation, will be small and useful enough to warrent
their inclusion. I would be more convinced if it was more than
just an unusual argument to gcc that was breaking.

I don't think it is a good idea to patch gcc to fix this
problem. If we are going to fix it, instead of working around
it on the command line itself, then we should do it by fixing
the library underneath the spawn calls. Patching gcc for this
failure in Win32 will only incur the ire of anti-win32 elements
within the GNU community, as well as being inefficient.

Of course, this isn't "my" code, and I have no real authority,
but I just wanted to put some of the issues I see on the table.

Just fishing for opinions,
Colin.

PS. I'm willing to make some work towards implementing those
    wrappers, although I can't say how quickly it will be done.

PPS. Jan-Jaap: I'd like to pass you a version of mingw32 0.1.5
     to do a once-over before I release it, if you have time.
     That would be some time next week I hope.

PPPS. Direct flames straight to me and keep the list free of
      napalm. :)

-- Colin Peters - Saga Univ. Dept. of Information Science
-- [email-masked] - finger for PGP public key
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".