From mboxrd@z Thu Jan 1 00:00:00 1970 From: Colin Peters To: "Pedro A. Aranda Gutiirrez" , "'Jan-Jaap van der Heijden'" Cc: "'GNU-Win32'" Subject: RE: mingw32 - noncygwin32 gcc - libwinserve.a Date: Thu, 16 Oct 1997 23:27:00 -0000 Message-id: <01BCDB11.0B047620@gbird0> X-SW-Source: 1997-10/msg00354.html Jan-Jaap van der Heijden[SMTP:janjaap@Wit381304.student.utwente.nl] 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 . 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 -- colin@bird.fu.is.saga-u.ac.jp - 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 "gnu-win32-request@cygnus.com" with one line of text: "help".