Re: 4.2 Project: "@file" support

Re: 4.2 Project: "@file" support

[Joern RENNECKE]

 > applications will just work, but introducing the very serious risk of
 > security problems, leading to, say:
 >
 > gcc: dj:yourpassword:1234:567:DJ: invalid argument
 >
 > instead of
 >
 > gcc: @/etc/passwd: invalid argument

If you want to use gcc to read a file, you get a closer likeness
to the data with:

gcc -E -C -x c /etc/passwd

Polluting argument name space seems more worrying.  A long option would 
not create
such ambiguities.

Re: 4.2 Project: "@file" support

[Alexandre Oliva]

On Aug 25, 2005, DJ Delorie <dj@redhat.com> wrote:

> If "@string" is seen, but "string" does not represent an existing
> file, the string "@string" is passed to the program as-is.

With the terrible side effect of letting people think their
applications will just work, but introducing the very serious risk of
security problems, leading to, say:

gcc: dj:yourpassword:1234:567:DJ: invalid argument

instead of 

gcc: @/etc/passwd: invalid argument


Sure this is probably not so much of an issue for GCC (although remote
compile servers are not totally unheard of), but it could easily
become a very serious problem for other applications that might take
filenames from the network and worry about quoting - but not @; those
would then need fixing.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: 4.2 Project: "@file" support

[Mark Mitchell]

DJ Delorie wrote:
>>However, I have a counter-proposal, which is that we use libiberty's
>>existing buildargv.
> 
> 
> I wasn't specifying DJGPP's exact code, mostly these features:

OK.

> 1. Recursion.  @file inside another @file causes further expansion.

Yes, my implementation happened to already do that.

(MSVC does not do this.  Presumably this explains the behavior under 3 
below.)

> 2. Support for "find -print0" which is more robust than
>    whitespace-delimited arguments.

OK.

> 3. Allow non-file "@string" left as-is (not fatal).

OK.

(MSVC does not do this either.)

I'm not particularly concerned about differing from MSVC on these 
points; I'm just noting them for posterity.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: 4.2 Project: "@file" support

[DJ Delorie]

> However, I have a counter-proposal, which is that we use libiberty's
> existing buildargv.

I wasn't specifying DJGPP's exact code, mostly these features:

1. Recursion.  @file inside another @file causes further expansion.

2. Support for "find -print0" which is more robust than
   whitespace-delimited arguments.

3. Allow non-file "@string" left as-is (not fatal).

Re: 4.2 Project: "@file" support

[Mark Mitchell]

DJ Delorie wrote:

> However, I don't see a way to do that for *all* OSs, and people seem
> to want that.  So while I won't actively support it in libiberty, I
> won't hinder it either.

Great!

> To make it as unobtrusive as possible, I request that the
> application-side only require one line:
> 
> 	functionname(&argc, &argv);
> 
> Let's name it something generic, and assume that *all* command line
> fiddling will be done within that function, and that the application
> never need worry about it - ever.

OK.

> I suggest that DJGPP's implementation define the functionality (at
> least, the parts that make sense to implmement globally), as we've had
> over a decade of experience with it, and thus it's likely to cause the
> least surprises:
> 
> http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/crt0/c1args.c?rev=1.10
> 
> (search for expand_response_files)

First, let me say that I don't feel strongly about anything after this 
point in this mail.  So, I can be pushed around pretty easily here; I'm 
more after some solution than any particular one.

I found the DJGPP code a little complicated, but I'm sure I can work it 
out.  I also did some additional experiments with MSVC and found some 
slightly odd behaviors, like double-quoting works, in general, but:

   "foo
   bar"

is actually two arguments.  I guess I'd argue that the behavior Windows 
people probably *most* expect is MSVC (rather than DJGPP), but that may 
not be true of GNU people in particular, who might be more likely to 
have used DJGPP.

However, I have a counter-proposal, which is that we use libiberty's 
existing buildargv.  That seems maximally consistent.  I didn't do that 
originally because I didn't know it was there, until very late in the 
game.  We would have to factor out the code so that we could avoid the 
buildargv behavior that creates a non-empty argv from an empty string, 
but other than that it seems like we could just leverage the quoting 
behavior that's already there.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: 4.2 Project: "@file" support

[Russ Allbery]

DJ Delorie <dj@redhat.com> writes:

>> gcc -c ./@foop.cpp
>> 
>> and of course the same goes for files with names that begin with '-'.

> That only works if the argument reflects a file name, and not some other
> syntactical sugar.  Granted, gcc has no such arguments, but libiberty
> has a wider scope than just gcc.

dig -t txt proxy-service.best.stanford.edu @leland-ns0

comes to mind.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: 4.2 Project: "@file" support

[Scott Robert Ladd]

Tristan Wibberley wrote:
> I certainly agree with (a). For (b), I think a gcc compiler that is
> intended to produce normal Windows binaries should have the same
> commandline interface as Microsoft's compiler (I mean *all* of the
> commandline interface) - for build scripts and development environments
> that expect to see Micrsoft's tools.

This isn;t that difficult to do now -- on Windows, I wrote a wrapper to 
mask the underlying compiler, so that tools expecting MSVC work 
transparently with Intel and GCC compilers. Emulating Microsoft exactly 
doesn't need to be part of GCC itself.

That said, I am a supported of the @file concept in GCC, since it has 
uses beyond simple MSVC compatibility.

..Scott

Re: 4.2 Project: "@file" support

[Tristan Wibberley]

Mark Mitchell wrote:
> Tristan Wibberley wrote:
> 
>> Mark Mitchell wrote:
>>
>>
>>
>>> However, there's demonstrable interest in this feature for GNU/Linux as
>>> well, from the lists, and for Java on all operating systems.
>>>
>>
>>
>> Please don't use '@filename' on Linux, use a normal switch with an
>> argument. The problems of '-' being used for switches is bad enough
>> without another valid filename character being overloaded. At least the
>> '-' problem is well understood and people can avoid using filenames
>> beginning with '-'.
> 
> 
> Again, I'm amenable to changes to the technical details.
> 
> The first step is agreeing that (a) the feature is beneficial, and (b)
> the mechanism for implementing it, such as whether it should be done in
> crt0 or in libiberty.  I think everyone's agreed on (a), but I don't
> think DJ and I are yet seeing eye-to-eye on (b).  Once we get past that,
> we can work out these details.

I certainly agree with (a). For (b), I think a gcc compiler that is
intended to produce normal Windows binaries should have the same
commandline interface as Microsoft's compiler (I mean *all* of the
commandline interface) - for build scripts and development environments
that expect to see Micrsoft's tools. If it also provides a gcc
commandline interface, it should look exectly like the *NIX gcc, and
long commandlines could be supported by *NIX style shells that use
CreateProcess wrappers such as exec to use IPC to pass the cmdline
(where libcrt handles it).

So if you use normal Windows tools to build, you can use the MS style
cmdline, and if you use ported GNU tools, you can use the GNU style
commandline (and both shell, make, etc. and compiler contain specific
support for long commandline via IPC).

More work, its true, but its also much nicer (IMHO).

My justification is that Windows programmers expect to use /F /OO:bar
and @argsfile commandline arguments from cmd, and Linux developers
working on Windows expect to use -f --oo=bar and --args=argsfile
commandline arguments from bash. So that is what they respectively ought
to be given. In the case of the GNU interface, it looks like the shell
and compiler are capable of long commandlines... use Microsoft
counterparts for either and you lose the facility and can fall back to
--args= or @. When GNU utilities are ported, libcrt and exec can
understand the long commandline method, when new programs are written
they can use an LGPL libWinGNU.dll that contains such functions as
LongCreateProcess (or link to a dll that contains its own CreateProcess
or something).

-- 
Tristan Wibberley

Opinions expressed are my own and do not necessarily coincide with those
of my employer, etc.

Re: 4.2 Project: "@file" support

[Laurent GUERBY]

On Fri, 2005-08-26 at 10:21 -0700, Ian Lance Taylor wrote:
> Sergei Organov <osv@topconrd.ru> writes:
> 
> > Anyway, my gcc docs only mention:
> > 
> > --target-help
> > --help
> > --version
> > --param NAME=VALUE
> 
> Yeah, it looks like the double dash long options got added without
> ever being documented.
> 
> For the record, they were added here:
> 
> Sat Mar  6 15:08:59 1993  Richard Stallman  (rms@mole.gnu.ai.mit.edu)
> 
> 	* gcc.c: Handle long options by translation to old-style ones.
> 	(translate_options): New function.
> 	(option_map): New table.
> 
> and the table has been kept more or less up to date ever since.

That's new news :). 

Anyway I was answering a proposal by D.J. to provide a library function
and my understanding was that it was intended to be used beyond GCC as a
portable way to implement file as argument list (even if a call has to
be added project by project), and in this GNU project context I believe
it makes sense to add a double dash long option for it even if GCC in
practice does not offer them.

Laurent

Re: 4.2 Project: "@file" support

[Ian Lance Taylor]

Sergei Organov <osv@topconrd.ru> writes:

> Anyway, my gcc docs only mention:
> 
> --target-help
> --help
> --version
> --param NAME=VALUE

Yeah, it looks like the double dash long options got added without
ever being documented.

For the record, they were added here:

Sat Mar  6 15:08:59 1993  Richard Stallman  (rms@mole.gnu.ai.mit.edu)

	* gcc.c: Handle long options by translation to old-style ones.
	(translate_options): New function.
	(option_map): New table.

and the table has been kept more or less up to date ever since.

Ian

Re: 4.2 Project: "@file" support

[Sergei Organov]

Ian Lance Taylor <ian@airs.com> writes:

> Sergei Organov <osv@topconrd.ru> writes:
> 
> > Laurent GUERBY <laurent@guerby.net> writes:
> > > If we add a library function to handle this we might want to
> > > add a GNU-style argument equivalent like
> > > 
> > > gcc --arguments-from-file=file
> > 
> > AFAIK gcc doesn't support any GNU-style arguments, isn't it?
> 
> Actually, it does, but they aren't widely documented.  For example,
> you can use --language instead of -x, etc.

My bad, -- confused by all that long options using single dash, sorry.

Anyway, my gcc docs only mention:

--target-help
--help
--version
--param NAME=VALUE

-- 
Sergei.

Re: 4.2 Project: "@file" support

[Ian Lance Taylor]

Sergei Organov <osv@topconrd.ru> writes:

> Laurent GUERBY <laurent@guerby.net> writes:
> > If we add a library function to handle this we might want to
> > add a GNU-style argument equivalent like
> > 
> > gcc --arguments-from-file=file
> 
> AFAIK gcc doesn't support any GNU-style arguments, isn't it?

Actually, it does, but they aren't widely documented.  For example,
you can use --language instead of -x, etc.

Ian

Re: 4.2 Project: "@file" support

[Sergei Organov]

Laurent GUERBY <laurent@guerby.net> writes:
> If we add a library function to handle this we might want to
> add a GNU-style argument equivalent like
> 
> gcc --arguments-from-file=file

AFAIK gcc doesn't support any GNU-style arguments, isn't it?

I'd consider

gcc @file
gcc -@ file
gcc -args-from-file file

-- 
Sergei.

Re: 4.2 Project: "@file" support

[DJ Delorie]

> Unless the @file contains a file that begins with a '\@' that got passed
> on to gcc, presumably.  I guess that would mean that you'd need to do
> some complicated quoting to actually pass a file beginning with '@' to
> gcc.

That's why DJGPP silently ignores @files that don't correspond to
files.  If you have some file @123.txt but don't have file 123.txt,
pass "@123.txt" to the program and it sees "@123.txt" in argv[].

The only time it's a problem is if you hae both @123.txt and 123.txt
as real files, then you can't pass "@123.txt" to argv[] without
quoting it (./@123.txt).

Re: 4.2 Project: "@file" support

[Laurent GUERBY]

If we add a library function to handle this we might want to
add a GNU-style argument equivalent like

gcc --arguments-from-file=file

Which would be equivalent to:

gcc @file

May be some GNU tools already have standardized on a long
argument name for such a feature, but none came to my mind
(and I'm not that proud of my proposed name :).

Laurent

PS: removed gcc-patches

Re: 4.2 Project: "@file" support

[Christopher Faylor]

On Thu, Aug 25, 2005 at 11:00:50AM -0400, DJ Delorie wrote:
>> FWIW, I should note that GCJ already has support for @file
>> style list of input files:
>> 
>>   http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
>> 
>> and has had it for quite some time now.
>
>DJGPP and Cygwin hosted programs will never see these options, because
>the runtime has already expanded them if appropriate.
>
>Which means your documentation is *wrong* for those platforms; for
>them, *any* command line option is legal in @file.

Unless the @file contains a file that begins with a '\@' that got passed
on to gcc, presumably.  I guess that would mean that you'd need to do
some complicated quoting to actually pass a file beginning with '@' to
gcc.

cgf

Re: 4.2 Project: "@file" support

[DJ Delorie]

> but I don't think DJ and I are yet seeing eye-to-eye on (b).

I think it's a bad idea to choose a solution that requires each
application (we have many) to be modified to call an extra function.
It would be far better to have the OS manage it transparently.

However, I don't see a way to do that for *all* OSs, and people seem
to want that.  So while I won't actively support it in libiberty, I
won't hinder it either.

To make it as unobtrusive as possible, I request that the
application-side only require one line:

	functionname(&argc, &argv);

Let's name it something generic, and assume that *all* command line
fiddling will be done within that function, and that the application
never need worry about it - ever.

DJGPP and Cygwin hosted programs won't ever use this, because @files
will already be expanded, but we can optimize that later.

I suggest that DJGPP's implementation define the functionality (at
least, the parts that make sense to implmement globally), as we've had
over a decade of experience with it, and thus it's likely to cause the
least surprises:

http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/crt0/c1args.c?rev=1.10

(search for expand_response_files)

Re: 4.2 Project: "@file" support

[Mark Mitchell]

Tristan Wibberley wrote:
> Mark Mitchell wrote:
> 
> 
> 
>>However, there's demonstrable interest in this feature for GNU/Linux as
>>well, from the lists, and for Java on all operating systems.
>>
> 
> 
> Please don't use '@filename' on Linux, use a normal switch with an
> argument. The problems of '-' being used for switches is bad enough
> without another valid filename character being overloaded. At least the
> '-' problem is well understood and people can avoid using filenames
> beginning with '-'.

Again, I'm amenable to changes to the technical details.

The first step is agreeing that (a) the feature is beneficial, and (b) 
the mechanism for implementing it, such as whether it should be done in 
crt0 or in libiberty.  I think everyone's agreed on (a), but I don't 
think DJ and I are yet seeing eye-to-eye on (b).  Once we get past that, 
we can work out these details.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: 4.2 Project: "@file" support

[Tristan Wibberley]

Mark Mitchell wrote:


> However, there's demonstrable interest in this feature for GNU/Linux as
> well, from the lists, and for Java on all operating systems.
> 

Please don't use '@filename' on Linux, use a normal switch with an
argument. The problems of '-' being used for switches is bad enough
without another valid filename character being overloaded. At least the
'-' problem is well understood and people can avoid using filenames
beginning with '-'.

-- 
Tristan Wibberley

Opinions expressed are my own and do not necessarily coincide with those
of my employer, etc.

Re: 4.2 Project: "@file" support

[Daniel Jacobowitz]

On Thu, Aug 25, 2005 at 10:51:42AM -0400, DJ Delorie wrote:
> 
> > I'm not sure how I can "fix MinGW"; see above.  Also, if a MinGW 
> > application wants to invoke some other Windows program, the behavior 
> > should be the same as if I compiled that application with Visual C, or 
> > Intel's C compiler, or whatever; if we were using magic to pass 
> > command-line arguments, we'd be breaking things.
> 
> No, the way DJGPP and Cygwin do it are twofold:
> 
> First, there's a *visible* support for @file, which would appear to
> act just like your patch supports (but with subtle differences).
> Non-DJGPP applications can use this to pass long command lines to
> DJGPP applications.  Same for Cygwin.
> 
> Second, both DJGPP and Cygwin have *hidden* methods for passing even
> longer command lines, more accurately, between DJGPP (or between
> Cygwin) applications.  I don't expect you to use this.
> 
> My suggestion is to take the patch you are proposing, and add it
> instead to MinGW's crt0 code.  That way, *ALL* applications built with
> MinGW would support @file on the command line, not just gcc.

In this case, I would propose adding it to _both_
libiberty/gcc/binutils, and mingw32, as separate improvements.  This
stuff is handy!  Not just for Windows users, but in plenty of other
circumstances too.  I'm of the opinion that the toolchain should
support it as a general convention, on any platform.

(That said I don't love the @filename syntax; but it could be worse,
and it seems fairly well-known...)

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: 4.2 Project: "@file" support

[Mark Mitchell]

DJ Delorie wrote:
>>feature even on Unix systems.  But on Unix systems I think we need to
>>at least consider the possibility of real source file names starting
>>with '@'.  The patch as it stands will have a rather perplexing effect
>>if such a file is compiled.  Maybe that's OK.
> 
> This is different from Mark's patch in that Mark's patch will cause
> the application to exit when some @string doesn't reflect a response
> file.

I'm not wedded to any of the technical details in my patch.  If we get 
to the point where all we have to do is agree on exactly how to handle 
these kinds of things, I would consider that a victory!

I based my implementation on some experimentation with MSVC and on 
reading the Microsoft documentation.  But, I wouldn't claim that I 
exhaustively matched the behavior; it wasn't well enough documented, and 
I didn't experiment heavily enough.

If a condition for acceptance is making "@string" silently accepted if 
"string" is not a file, for example, I'll happily implement that.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: 4.2 Project: "@file" support

[Daniel Jacobowitz]

On Thu, Aug 25, 2005 at 10:27:12AM -0700, Ian Lance Taylor wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
> > I've created a new 4.2 Project page for "response files", which is
> > what Microsoft calls files that contain command-line options.
> > Conventionally, if you pass "@file" as an argument to a program, the
> > file is read, and the contents are treated as command-line options.
> > On systems with small command-line buffers, this is a must-have
> > feature.
> 
> Without getting into whether it's a good idea to overcome OS
> limitations in this way, I do think that response files are a useful
> feature even on Unix systems.  But on Unix systems I think we need to
> at least consider the possibility of real source file names starting
> with '@'.  The patch as it stands will have a rather perplexing effect
> if such a file is compiled.  Maybe that's OK.

Personally, I think that's OK.  Document ./@file.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: 4.2 Project: "@file" support

[DJ Delorie]

> gcc -c ./@foop.cpp
> 
> and of course the same goes for files with names that begin with '-'.

That only works if the argument reflects a file name, and not some
other syntactical sugar.  Granted, gcc has no such arguments, but
libiberty has a wider scope than just gcc.

Re: 4.2 Project: "@file" support

[DJ Delorie]

> feature even on Unix systems.  But on Unix systems I think we need to
> at least consider the possibility of real source file names starting
> with '@'.  The patch as it stands will have a rather perplexing effect
> if such a file is compiled.  Maybe that's OK.

What DJGPP and Cygwin do is thusly: If "@string" is seen, but "string"
does not represent an existing file, the string "@string" is passed to
the program as-is.  This allows for arguments (not always file names!)
that start with @, and in most cases where you intend to specify a
file but spell it wrong, the application will usually give a
meaningful error about the odd parameter you've just given it.

This is different from Mark's patch in that Mark's patch will cause
the application to exit when some @string doesn't reflect a response
file.

DJGPP at least also supports simple quoting and recursion in response
files.  It also checks for NUL-delimited arguments, from "find
-print0", as an alternative to whitespace-delimited arguments.

Borland C had a similar function for expanding wildcards, which the
user could add to their applications, something like this:

main(int argc, char **argv)
{
  expand_wildcards(&argc, *argv);
  ..

Note that in no case do these expansion functions trigger a fatal
error; they just revert to the original command line arguments if they
can't expand them.

Re: 4.2 Project: "@file" support

[Joe Buck]

On Thu, Aug 25, 2005 at 10:27:12AM -0700, Ian Lance Taylor wrote:
> [ re: @file ]

> Without getting into whether it's a good idea to overcome OS
> limitations in this way, I do think that response files are a useful
> feature even on Unix systems.  But on Unix systems I think we need to
> at least consider the possibility of real source file names starting
> with '@'.  The patch as it stands will have a rather perplexing effect
> if such a file is compiled.  Maybe that's OK.

Users are unlikely to name files in that way, but if for some reason
they want to, they can just write

gcc -c ./@foop.cpp

and of course the same goes for files with names that begin with '-'.

So I don't think this is much of an argument.

Re: 4.2 Project: "@file" support

[Ian Lance Taylor]

Mark Mitchell <mark@codesourcery.com> writes:

> I've created a new 4.2 Project page for "response files", which is
> what Microsoft calls files that contain command-line options.
> Conventionally, if you pass "@file" as an argument to a program, the
> file is read, and the contents are treated as command-line options.
> On systems with small command-line buffers, this is a must-have
> feature.

Without getting into whether it's a good idea to overcome OS
limitations in this way, I do think that response files are a useful
feature even on Unix systems.  But on Unix systems I think we need to
at least consider the possibility of real source file names starting
with '@'.  The patch as it stands will have a rather perplexing effect
if such a file is compiled.  Maybe that's OK.

Ian

Re: 4.2 Project: "@file" support

[Gabriel Paubert]

On Thu, Aug 25, 2005 at 06:09:25PM +0200, Florian Weimer wrote:
> * Andi Kleen:
> 
> > Linux has a similar limit which comes from the OS (normally around 32k) 
> > So it would be useful there for extreme cases too.
> 
> IIRC, FreeBSD has a rather low limit, too.  And there were discussions
> about command line length problems in the GCC build process on VMS.

For the record, the @file technique is a pretty standard way of
providing long command lines under VMS since the late seventies
or so. Many of our link scripts use it.

However, I suspect that the @file parsing only happens for
commands known to DCL, not for "foreign" commands.

	Gabriel

RE: 4.2 Project: "@file" support

[Douglas B Rupp]

 

> And there were discussions about command line length problems in the GCC
build process on VMS.

The problem on VMS is not so much total command line length as element
length, e.g. strlen (argv [x]).  A single element cannot exceed 1024
characters or something like that (have to look it up to be sure).

--Douglas Rupp
AdaCore

Re: 4.2 Project: "@file" support

[H. J. Lu]

On Thu, Aug 25, 2005 at 06:09:25PM +0200, Florian Weimer wrote:
> * Andi Kleen:
> 
> > Linux has a similar limit which comes from the OS (normally around 32k) 
> > So it would be useful there for extreme cases too.
> 
> IIRC, FreeBSD has a rather low limit, too.  And there were discussions
> about command line length problems in the GCC build process on VMS.

I think MS linker can take a file as command line argument or something
like that. It may come handy sometimes. BTW, will it help C++ export
implementation?


H.J.

Re: 4.2 Project: "@file" support

[Florian Weimer]

* Andi Kleen:

> Linux has a similar limit which comes from the OS (normally around 32k) 
> So it would be useful there for extreme cases too.

IIRC, FreeBSD has a rather low limit, too.  And there were discussions
about command line length problems in the GCC build process on VMS.

Re: 4.2 Project: "@file" support

[Ranjit Mathew]

On 8/25/05, DJ Delorie <dj@redhat.com> wrote:
> 
> > FWIW, I should note that GCJ already has support for @file
> > style list of input files:
> >
> >   http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
> >
> > and has had it for quite some time now.
> 
> DJGPP and Cygwin hosted programs will never see these options, because
> the runtime has already expanded them if appropriate.
> 
> Which means your documentation is *wrong* for those platforms; for
> them, *any* command line option is legal in @file.  Please update your
> documentation ;-)

GCJ supports them because Sun's javac supports them:

  http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html

Sun's javac seems to have the same semantics as that you describe
(options, source files, etc.) while GCJ seems to support only source
files in "@file" files.

So at least on DJGPP/Cygwin, GCJ would appear to be more
compatible with Sun's javac than it really is. :-)

Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://ranjitmathew.hostingzero.com/

Re: 4.2 Project: "@file" support

[DJ Delorie]

> Yup. Simple things like 'ls *' or 'rm -rf a*' can bring you all the joy.

I hesitate to point out that the problem isn't long command lines per
se, it's that we have a poor way of specifying large quantities of
information that, perhaps, belongs in an include file somehow.

#define FOOINC "/usr/local/foo/bar.h"
#include FOOINC
#define OPTION 4
#include "@GTKDIR@/gtk.h"

Re: 4.2 Project: "@file" support

[Tom Tromey]

>>>>> "Ranjit" == Ranjit Mathew <rmathew@gmail.com> writes:

Ranjit> FWIW, I should note that GCJ already has support for @file
Ranjit> style list of input files:
Ranjit>   http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
Ranjit> and has had it for quite some time now.

Also, the interpretation of this for java compilers is quasi-defined.
Jacks has a few 'non-jls' tests for this functionality.  It would be
nice not to fail any of these.

Tom

Re: 4.2 Project: "@file" support

[Robert Dewar]

DJ Delorie wrote:

> Only on one out of three supported windows platforms.  The other two
> already have it as part of the "os".

but that one out of three is by far the most
important one in practice!

Re: 4.2 Project: "@file" support

[Mark Mitchell]

DJ Delorie wrote:
>>I'm not sure how I can "fix MinGW"; see above.  Also, if a MinGW 
>>application wants to invoke some other Windows program, the behavior 
>>should be the same as if I compiled that application with Visual C, or 
>>Intel's C compiler, or whatever; if we were using magic to pass 
>>command-line arguments, we'd be breaking things.

> My suggestion is to take the patch you are proposing, and add it
> instead to MinGW's crt0 code.  That way, *ALL* applications built with
> MinGW would support @file on the command line, not just gcc.

But, that would change the behavior for applications that may not want 
that.  That's what I was trying to communicate above.  One of the 
benefits of MinGW is that you can write code that compiles and behaves 
identically with MSVC, ICC, or GCC.  If we did as you suggest, we would 
violate that invariant.

A similar argument would apply to the shell-script stuff that was just 
added to libiberty.  Why not just have MinGW wrap CreateProcess and do 
shebang handling there?  Because only some applications what that 
functionality.

I agree that it would be technically feasible to create a different 
version of MinGW crt0 code that users could optionally select when they 
want @-file behavior in an application.  (Of course, we could do that 
for shebang handling too.)

However, there's demonstrable interest in this feature for GNU/Linux as 
well, from the lists, and for Java on all operating systems.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: 4.2 Project: "@file" support

[DJ Delorie]

> FWIW, I should note that GCJ already has support for @file
> style list of input files:
> 
>   http://gcc.gnu.org/onlinedocs/gcj/Input-and-output-files.html
> 
> and has had it for quite some time now.

DJGPP and Cygwin hosted programs will never see these options, because
the runtime has already expanded them if appropriate.

Which means your documentation is *wrong* for those platforms; for
them, *any* command line option is legal in @file.  Please update your
documentation ;-)

Re: 4.2 Project: "@file" support

[DJ Delorie]

> Mark's patch is apparently necessary for good Windows support,

Only on one out of three supported windows platforms.  The other two
already have it as part of the "os".

Re: 4.2 Project: "@file" support

[DJ Delorie]

> I'm not sure how I can "fix MinGW"; see above.  Also, if a MinGW 
> application wants to invoke some other Windows program, the behavior 
> should be the same as if I compiled that application with Visual C, or 
> Intel's C compiler, or whatever; if we were using magic to pass 
> command-line arguments, we'd be breaking things.

No, the way DJGPP and Cygwin do it are twofold:

First, there's a *visible* support for @file, which would appear to
act just like your patch supports (but with subtle differences).
Non-DJGPP applications can use this to pass long command lines to
DJGPP applications.  Same for Cygwin.

Second, both DJGPP and Cygwin have *hidden* methods for passing even
longer command lines, more accurately, between DJGPP (or between
Cygwin) applications.  I don't expect you to use this.

My suggestion is to take the patch you are proposing, and add it
instead to MinGW's crt0 code.  That way, *ALL* applications built with
MinGW would support @file on the command line, not just gcc.

Re: 4.2 Project: "@file" support

[Marcin Dalecki]

On 2005-08-25, at 13:57, Paolo Bonzini wrote:

> Marcin Dalecki wrote:
>
>> On 2005-08-25, at 09:14, Christoph Hellwig wrote:
>>
>>> That's what I meant with my comment btw.  It's a horrible idea to
>>> put in all the junk to support inferior OSes into gcc and all other
>>> other programs, and with cygwin and djgpp there are already two nice
>>> enviroments for that.
>>>
>> man xargs?
>>
>
> How are you going to use xargs for
>
>    gcc -o myprog `find $dir -name "*.c"`
>
> If $dir is 50 characters long, it only takes 500 files before it  
> overflows a 32k command line.

It was meant to suggest that the supposedly inferior system just  
imposes a lower limit which exists on the other system as well. It  
was an example of "junk" in the supposedly not inferior OS. Some  
people simply apparently have gone snow blind. Perhaps because they  
where living for too long only among penguins?

> @file was a *very* useful feature when I worked on compiling  
> libjava one directory at a time.  And it solved PR20155 as well.

Yes it is *very* useful IMHO.

Re: 4.2 Project: "@file" support

[Paolo Bonzini]

Marcin Dalecki wrote:
> 
> On 2005-08-25, at 09:14, Christoph Hellwig wrote:
> 
>> That's what I meant with my comment btw.  It's a horrible idea to
>> put in all the junk to support inferior OSes into gcc and all other
>> other programs, and with cygwin and djgpp there are already two nice
>> enviroments for that.
> 
> man xargs?

How are you going to use xargs for

    gcc -o myprog `find $dir -name "*.c"`

If $dir is 50 characters long, it only takes 500 files before it 
overflows a 32k command line.

@file was a *very* useful feature when I worked on compiling libjava one 
directory at a time.  And it solved PR20155 as well.

Paolo

Re: 4.2 Project: "@file" support

[Marcin Dalecki]

On 2005-08-25, at 09:14, Christoph Hellwig wrote:

> That's what I meant with my comment btw.  It's a horrible idea to
> put in all the junk to support inferior OSes into gcc and all other
> other programs, and with cygwin and djgpp there are already two nice
> enviroments for that.

man xargs?

Re: 4.2 Project: "@file" support

[Robert Dewar]

Andi Kleen wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> 
>>I'm not sure what you're saying.  The limitation on command-line
>>length can be in either the shell, or the OS.  In Windows 2000, the
>>limitation comes primarily from the Windows command shell.
> 
> 
> Linux has a similar limit which comes from the OS (normally around 32k) 
> So it would be useful there for extreme cases too.

Not so extreme, we have seen people run into this problem on
GNU/Linux systems fairly often. It seems defective design to
me for any OS to have such silly limits, but the fact is that many do!

Re: 4.2 Project: "@file" support

[Robert Dewar]

> GCC supports many proprietary systems and non-GNU systems, even
> though that isn't the purpose of the GCC project according to the
> mission statement.  Not everyone is happy about that, but that's
> just the way it is.  IMHO if you're going to support proprietary
> systems then you might as well try your best at it.  Mark's patch
> is apparently necessary for good Windows support, and something
> that other compilers there support, so why not have it in GCC?

I agree, and I think the patch is ver useful. Problems with
command line length are a recurrent nuisance, and it is good to
have a uniform solution, rather than a lot of patchwork.

Re: 4.2 Project: "@file" support

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Thu, 2005-08-25 12:49:16 +0200, Andi Kleen <ak@suse.de> wrote:
> On Thursday 25 August 2005 12:45, Jan-Benedict Glaw wrote:
> > Linux uses 32 pages, which results in 128KB on 4K architecture (eg.
> > i386, m68k, sparc32, ...) or 256KB on 8K architectures (eg. Alpha,
> > UltraSparc, ...).
> 
> Yes you're right. Somehow I only remembered the number 32.
> Anyways, it's still too small. I regularly run into the limit, although
> normally not with gcc.

Yup. Simple things like 'ls *' or 'rm -rf a*' can bring you all the joy.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 4.2 Project: "@file" support

[Andi Kleen]

On Thursday 25 August 2005 12:45, Jan-Benedict Glaw wrote:

> Linux uses 32 pages, which results in 128KB on 4K architecture (eg.
> i386, m68k, sparc32, ...) or 256KB on 8K architectures (eg. Alpha,
> UltraSparc, ...).

Yes you're right. Somehow I only remembered the number 32.
Anyways, it's still too small. I regularly run into the limit, although
normally not with gcc.

-Andi

Re: 4.2 Project: "@file" support

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

On Thu, 2005-08-25 12:31:34 +0200, Andi Kleen <ak@suse.de> wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
> > I'm not sure what you're saying.  The limitation on command-line
> > length can be in either the shell, or the OS.  In Windows 2000, the
> > limitation comes primarily from the Windows command shell.
> 
> Linux has a similar limit which comes from the OS (normally around 32k) 
> So it would be useful there for extreme cases too.

Linux uses 32 pages, which results in 128KB on 4K architecture (eg.
i386, m68k, sparc32, ...) or 256KB on 8K architectures (eg. Alpha,
UltraSparc, ...).

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 für einen Freien Staat voll Freier Bürger"  | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 4.2 Project: "@file" support

[Richard Kenner]

    I want GCC to work well for people, no matter what operating system they 
    are using.  This is a feature that everyone who produces Windows-hosted 
    versions of GCC ends up implementing; I'd like to keep us all from 
    having to keep reinventing the wheel.

Indeed there's a quite old version of this that somebody I know wrote that
I kept putting off dealing with ...

Re: 4.2 Project: "@file" support

[Andi Kleen]

Mark Mitchell <mark@codesourcery.com> writes:
> 
> I'm not sure what you're saying.  The limitation on command-line
> length can be in either the shell, or the OS.  In Windows 2000, the
> limitation comes primarily from the Windows command shell.

Linux has a similar limit which comes from the OS (normally around 32k) 
So it would be useful there for extreme cases too.

-Andi

Re: 4.2 Project: "@file" support

[Steven Bosscher]

On Thursday 25 August 2005 07:12, Christoph Hellwig wrote:
> > On systems with small command-line buffers, this is a must-have
> > feature.
>
> Do you really want every application to work around a broken propritary
> system?

GCC supports many proprietary systems and non-GNU systems, even
though that isn't the purpose of the GCC project according to the
mission statement.  Not everyone is happy about that, but that's
just the way it is.  IMHO if you're going to support proprietary
systems then you might as well try your best at it.  Mark's patch
is apparently necessary for good Windows support, and something
that other compilers there support, so why not have it in GCC?

> Looks like gcc is really heading down the wrong way..

So which way would you suggest it should go?

Gr.
Steven

Re: 4.2 Project: "@file" support

[Mark Mitchell]

Christoph Hellwig wrote:

> That's what I meant with my comment btw.  It's a horrible idea to
> put in all the junk to support inferior OSes into gcc and all other
> other programs, and with cygwin and djgpp there are already two nice
> enviroments for that.  If Mark wants to duplicate that in MinGw that's
> of course fine aswell..

I cannot see any way to "fix" MinGW so that a user using a Windows 
command shell can invoke GCC with a long command line; by the time GCC 
is invoked, the command has already been truncated.  That's why most 
(all?) compilers for Windows have "@file" or equivalent.

The obvious suggestion is that the user should use a "real" shell. 
However, since the user is often not invoking the compiler directly, but 
is instead using an IDE or some make program, that's not a practical option.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: 4.2 Project: "@file" support

[Christoph Hellwig]

On Thu, Aug 25, 2005 at 01:29:05AM -0400, DJ Delorie wrote:
> It sounds like you're interested in MinGW.  If you really wanted to
> help MinGW users, you'd fix MinGW so that it supported these the same
> way that DJGPP and Cygwin do, for *all* MinGW applications, not just
> gcc.  I'd have to have to manually add this function call to each of
> the programs in binutils, gdb, sid, fileutils, coreutils, make, etc.
> That sounds like the wrong way to solve an OS problem.

That's what I meant with my comment btw.  It's a horrible idea to
put in all the junk to support inferior OSes into gcc and all other
other programs, and with cygwin and djgpp there are already two nice
enviroments for that.  If Mark wants to duplicate that in MinGw that's
of course fine aswell..

Re: 4.2 Project: "@file" support

[Mark Mitchell]

DJ Delorie wrote:

> It sounds like you're interested in MinGW.  

Yes.  I'm particularly interested in the case of applications not built 
with GCC invoking GCC.  I can't control the invoker; only the invokee.

 > If you really wanted > help MinGW users, you'd fix MinGW so that it 
supported these the same
> way that DJGPP and Cygwin do, for *all* MinGW applications, not just
> gcc.  I'd have to have to manually add this function call to each of
> the programs in binutils, gdb, sid, fileutils, coreutils, make, etc.
> That sounds like the wrong way to solve an OS problem.

I'm not sure how I can "fix MinGW"; see above.  Also, if a MinGW 
application wants to invoke some other Windows program, the behavior 
should be the same as if I compiled that application with Visual C, or 
Intel's C compiler, or whatever; if we were using magic to pass 
command-line arguments, we'd be breaking things.

We have the same OS problem in almost every UNIX, to one degree or 
another.  Older UNIX variants certainly had this problem in spades.  But 
it's not a big deal to me if people don't want this for systems other 
than MinGW, but I think we need it for MinGW.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: 4.2 Project: "@file" support

[Mark Mitchell]

DJ Delorie wrote:
>>I'm not sure what you're saying.  The limitation on command-line
>>length can be in either the shell, or the OS.  In Windows 2000, the
>>limitation comes primarily from the Windows command shell.
> 
> 
> When gcc.exe invokes cc1.exe, the limitation is not the command shell.

Correct.

In Windows, there is much less of a limitation there; CreateProcess has 
a 32K limit.  However, Win2K's command shell was much more limited. 
Therefore, the primary problem is in getting arguments into the driver; 
getting things from the driver to subprocesses is much less problematic, 
in practice.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: 4.2 Project: "@file" support

[DJ Delorie]

> I'm not sure what you're saying.  The limitation on command-line
> length can be in either the shell, or the OS.  In Windows 2000, the
> limitation comes primarily from the Windows command shell.

When gcc.exe invokes cc1.exe, the limitation is not the command shell.

Re: 4.2 Project: "@file" support

[DJ Delorie]

Mark Mitchell <mark@codesourcery.com> writes:
> I've created a new 4.2 Project page for "response files", which is
> what Microsoft calls files that contain command-line options.
> Conventionally, if you pass "@file" as an argument to a program, the
> file is read, and the contents are treated as command-line options.
> On systems with small command-line buffers, this is a must-have
> feature.

DJGPP and Cygwin already implement these at the OS level, for *all*
applications, and have for quite some time now.  Please don't
interfere with this; it will only confuse DJGPP and Cygwin users,
especially since your implementation is already different than
existing implementations.

Also, both DJGPP and Cygwin programs have essentially unlimited
command line buffers when invoked from other DJGPP or Cygwin programs
(like "make"); they use an internal interface to bypass the OS
limitations.

It sounds like you're interested in MinGW.  If you really wanted to
help MinGW users, you'd fix MinGW so that it supported these the same
way that DJGPP and Cygwin do, for *all* MinGW applications, not just
gcc.  I'd have to have to manually add this function call to each of
the programs in binutils, gdb, sid, fileutils, coreutils, make, etc.
That sounds like the wrong way to solve an OS problem.

Re: 4.2 Project: "@file" support

[Mark Mitchell]

Christoph Hellwig wrote:
> On Wed, Aug 24, 2005 at 09:50:32PM -0700, Mark Mitchell wrote:
> 
>>I've created a new 4.2 Project page for "response files", which is
>>what Microsoft calls files that contain command-line options.
>>Conventionally, if you pass "@file" as an argument to a program, the
>>file is read, and the contents are treated as command-line options.
> 
> Huh?  That should certainly be a feature of the shell, not the OS.

I'm not sure what you're saying.  The limitation on command-line length 
can be in either the shell, or the OS.  In Windows 2000, the limitation 
comes primarily from the Windows command shell.

>>On systems with small command-line buffers, this is a must-have
>>feature.
> 
> Do you really want every application to work around a broken propritary
> system?

I want GCC to work well for people, no matter what operating system they 
are using.  This is a feature that everyone who produces Windows-hosted 
versions of GCC ends up implementing; I'd like to keep us all from 
having to keep reinventing the wheel.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: 4.2 Project: "@file" support

[Christoph Hellwig]

On Wed, Aug 24, 2005 at 09:50:32PM -0700, Mark Mitchell wrote:
> 
> I've created a new 4.2 Project page for "response files", which is
> what Microsoft calls files that contain command-line options.
> Conventionally, if you pass "@file" as an argument to a program, the
> file is read, and the contents are treated as command-line options.


Huh?  That should certainly be a feature of the shell, not the OS.

> On systems with small command-line buffers, this is a must-have
> feature.

Do you really want every application to work around a broken propritary
system?  Looks like gcc is really heading down the wrong way..

4.2 Project: "@file" support

[Mark Mitchell]

I've created a new 4.2 Project page for "response files", which is
what Microsoft calls files that contain command-line options.
Conventionally, if you pass "@file" as an argument to a program, the
file is read, and the contents are treated as command-line options.
On systems with small command-line buffers, this is a must-have
feature.

This is clearly not Stage 3 material.  I'm posting it now in the hopes
that any issues can be resolved in advance of 4.2 Stage 1.  Also,
because this patch comes from a 3.4 toolchain, I know there are a few
updates (like using XRESIZEVEC) that should be made before committing
to mainline.

And, as penance for posting new features in Stage 3, I'm committing to
fixing some C++ bugs before bedtime.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

2005-08-24  Mark Mitchell  <mark@codesourcery.com>

	* include/libiberty.h (expandargv): New function.
	* libiberty/argv.c (safe-ctype.h): Include it.
	(ISBLANK): Remove.
	(stdio.h): Include.
	(expandargv): New function.
	* libiberty/Makefile.in: Regenerated.
	* gcc/gcc.c (main): Use expandargv.
	* gcc/doc/invoke.texi: Describe "@file" option. 

Index: include/libiberty.h
===================================================================
RCS file: /cvs/gcc/gcc/include/libiberty.h,v
retrieving revision 1.35.10.1
diff -c -5 -p -r1.35.10.1 libiberty.h
*** include/libiberty.h	23 Dec 2003 17:25:29 -0000	1.35.10.1
--- include/libiberty.h	25 Aug 2005 03:31:49 -0000
*************** extern void freeargv PARAMS ((char **));
*** 60,69 ****
--- 60,72 ----
  /* Duplicate an argument vector. Allocates memory using malloc.  Use
     freeargv to free the vector.  */
  
  extern char **dupargv PARAMS ((char **)) ATTRIBUTE_MALLOC;
  
+ /* Expand "@file" arguments in argv.  */
+ 
+ extern const char *expandargv PARAMS ((int *, char ***));
  
  /* Return the last component of a path name.  Note that we can't use a
     prototype here because the parameter is declared inconsistently
     across different systems, sometimes as "char *" and sometimes as
     "const char *" */
Index: libiberty/argv.c
===================================================================
RCS file: /cvs/gcc/gcc/libiberty/argv.c,v
retrieving revision 1.13
diff -c -5 -p -r1.13 argv.c
*** libiberty/argv.c	15 Apr 2003 20:36:33 -0000	1.13
--- libiberty/argv.c	25 Aug 2005 03:31:49 -0000
*************** Boston, MA 02111-1307, USA.  */
*** 22,33 ****
  /*  Create and destroy argument vectors.  An argument vector is simply an
      array of string pointers, terminated by a NULL pointer. */
  
  #include "ansidecl.h"
  #include "libiberty.h"
  
! #define ISBLANK(ch) ((ch) == ' ' || (ch) == '\t')
  
  /*  Routines imported from standard C runtime libraries. */
  
  #ifdef ANSI_PROTOTYPES
  
--- 22,34 ----
  /*  Create and destroy argument vectors.  An argument vector is simply an
      array of string pointers, terminated by a NULL pointer. */
  
  #include "ansidecl.h"
  #include "libiberty.h"
+ #include "safe-ctype.h"
  
! #include <stdio.h>
  
  /*  Routines imported from standard C runtime libraries. */
  
  #ifdef ANSI_PROTOTYPES
  
*************** char **buildargv (input)
*** 302,311 ****
--- 303,457 ----
        while (*input != EOS);
      }
    return (argv);
  }
  
+ /*
+ 
+ @deftypefn Extension const char* expandargv (int *@var{argcp}, char ***@var{argvp})
+ 
+ The @var{argcp} and @code{argvp} arguments are pointers to the usual
+ @code{argc} and @code{argv} arguments to @code{main}.  This function
+ looks for arguments that begin with the character @samp{@@}.  Any such
+ arguments are interpreted as ``response files''.  The contents of the
+ response file are interpreted as additional command line options.  In
+ particular, the file is separated into whitespace-separated strings;
+ each such string is taken as a command-line option.  The new options
+ are inserted in place of the option naming the response file, and
+ @code{*argcp} and @code{*argvp} will be updated.  If the value of
+ @code{*argvp} is modified by this function, then the new value has
+ been dynamically allocated and should be deallocated by the caller
+ with @code{freeargv}.
+ 
+ If the value returned is not @code{NULL}, then it is the name of a
+ response file that could not be read.
+ 
+ @end deftypefn
+ 
+ */
+ 
+ const char *
+ expandargv (argcp, argvp)
+      int *argcp;
+      char ***argvp;
+ {
+   /* A dynamically allocated buffer used to hold options read from a
+      response file.  NULL until needed.  */
+   char *buffer = NULL;
+   /* The number of bytes in BUFFER.  */
+   size_t buffer_len = 0;
+   /* Dynamically allocated storage for the options read from the
+      response file.  NULL until needed.  */
+   char **file_options = NULL;
+   /* The number of slots in the FILE_OPTIONS array.  */
+   size_t file_options_len = 0;
+   /* If non-NULL, the name of the response file that caused a
+      failure.  */
+   const char *error_file = NULL;
+   /* The argument we are currently processing.  */
+   int i = 0;
+   /* Non-zero if ***argvp has been dynamically allocated.  */
+   int argv_dynamic = 0;
+ 
+   /* Loop over the arguments, handling response files.  We always skip
+      ARGVP[0], as that is the name of the program being run.  */
+   while (++i != *argcp)
+     {
+       /* The name of the response file.  */
+       const char *filename;
+       /* The response file.  */
+       FILE *f;
+       /* The number of options read from the response file, if any.  */
+       size_t num_options;
+ 
+       /* We are only interested in options of the form "@file".  */
+       filename = (*argvp)[i];
+       if (filename[0] != '@')
+ 	continue;
+ 
+       /* Open the file.  */
+       f = fopen (++filename, "r");
+       if (!f)
+ 	{
+ 	  error_file = filename;
+ 	  goto done;
+ 	}
+ 
+       /* Read all the options.  */
+       num_options = 0;
+       while (1)
+ 	{
+ 	  /* The insertion point in BUFFER.  */
+ 	  size_t buffer_pos = 0;
+ 	  /* The character immediately following the option in
+ 	     BUFFER.  */
+ 	  int c;
+ 	  /* Read the next option from the file.  */
+ 	  while (1)
+ 	    {
+ 	      if (buffer_pos + 32 > buffer_len)
+ 		{
+ 		  buffer_len = buffer_len ? 2 * buffer_len : 32;
+ 		  buffer = (char *) xrealloc (buffer, buffer_len);
+ 		}
+ 	      c = fscanf (f, "%31s", buffer + buffer_pos);
+ 	      if (c == EOF)
+ 		break;
+ 	      /* If the next character in the file is not whitespace,
+ 		 then we didn't yet read the entire argument.  */
+ 	      c = getc (f);
+ 	      if (c == EOF || ISSPACE (c))
+ 		break;
+ 	      /* Put back the character at which we peeked.  */
+ 	      ungetc (c, f);
+ 	      buffer_pos += 31;
+ 	    }
+ 	  if (c == EOF)
+ 	    break;
+ 	  /* Insert the option into FILE_OPTIONS.  */
+ 	  if (num_options == file_options_len)
+ 	    {
+ 	      file_options_len = file_options_len ? 2 * file_options_len : 32;
+ 	      file_options
+ 		= (char **) xrealloc (file_options,
+ 				      file_options_len * sizeof (char *));
+ 	    }
+ 	  file_options[num_options++] = xstrdup(buffer);
+ 	}
+ 
+       /* We're done with the file now.  */
+       fclose (f);
+       /* Insert all the options into ARGV.  */
+       if (!argv_dynamic)
+ 	{
+ 	  *argvp = dupargv (*argvp);
+ 	  if (!*argvp)
+ 	    /* We do not know exactly many bytes dupargv tried to
+ 	       allocate, so make a guess.  */
+ 	    xmalloc_failed (*argcp * 32);
+ 	}
+       /* The "+1" below handles the NULL terminator at the end of ARGV.  */
+       *argvp = ((char **) 
+ 		xrealloc (*argvp, 
+ 			  (*argcp + num_options + 1) * sizeof (char *)));
+       memmove (*argvp + i + num_options, *argvp + i + 1, 
+ 	       (*argcp - i) * sizeof (char *));
+       memcpy (*argvp + i, file_options, num_options * sizeof (char *));
+       /* The original option has been replaced by all the new
+ 	 options.  */
+       *argcp += num_options - 1;
+     }
+ 
+  done:
+   if (buffer)
+     free (buffer);
+   if (file_options)
+     free (file_options);
+ 
+   return error_file;
+ }
+ 
  #ifdef MAIN
  
  /* Simple little test driver. */
  
  static const char *const tests[] =
Index: libiberty/Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/libiberty/Makefile.in,v
retrieving revision 1.93.8.2
diff -c -5 -p -r1.93.8.2 Makefile.in
*** libiberty/Makefile.in	3 Mar 2004 16:05:26 -0000	1.93.8.2
--- libiberty/Makefile.in	25 Aug 2005 03:37:55 -0000
*************** $(CONFIGURED_OFILES): stamp-picdir
*** 415,425 ****
  # The dependencies in the remainder of this file are automatically
  # generated by "make maint-deps".  Manual edits will be lost.
  
  _doprnt.o: config.h $(INCDIR)/ansidecl.h $(INCDIR)/safe-ctype.h
  alloca.o: config.h $(INCDIR)/ansidecl.h $(INCDIR)/libiberty.h
! argv.o: $(INCDIR)/ansidecl.h $(INCDIR)/libiberty.h
  asprintf.o: $(INCDIR)/ansidecl.h $(INCDIR)/libiberty.h
  atexit.o: config.h
  basename.o: $(INCDIR)/ansidecl.h $(INCDIR)/libiberty.h \
  	$(INCDIR)/safe-ctype.h
  bsearch.o: config.h $(INCDIR)/ansidecl.h
--- 415,426 ----
  # The dependencies in the remainder of this file are automatically
  # generated by "make maint-deps".  Manual edits will be lost.
  
  _doprnt.o: config.h $(INCDIR)/ansidecl.h $(INCDIR)/safe-ctype.h
  alloca.o: config.h $(INCDIR)/ansidecl.h $(INCDIR)/libiberty.h
! argv.o: $(INCDIR)/ansidecl.h $(INCDIR)/libiberty.h \
! 	$(INCDIR)/safe-ctype.h
  asprintf.o: $(INCDIR)/ansidecl.h $(INCDIR)/libiberty.h
  atexit.o: config.h
  basename.o: $(INCDIR)/ansidecl.h $(INCDIR)/libiberty.h \
  	$(INCDIR)/safe-ctype.h
  bsearch.o: config.h $(INCDIR)/ansidecl.h
Index: gcc/gcc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gcc.c,v
retrieving revision 1.395.2.10
diff -c -5 -p -r1.395.2.10 gcc.c
*** gcc/gcc.c	27 Jul 2005 20:27:14 -0000	1.395.2.10
--- gcc/gcc.c	25 Aug 2005 03:31:49 -0000
*************** main (int argc, const char **argv)
*** 5990,5999 ****
--- 5990,6005 ----
    /* We *MUST* set SIGCHLD to SIG_DFL so that the wait4() call will
       receive the signal.  A different setting is inheritable */
    signal (SIGCHLD, SIG_DFL);
  #endif
  
+   {
+     const char *response_file = expandargv (&argc, &argv);
+     if (response_file)
+       pfatal_with_name (response_file);
+   }
+ 
    /* Allocate the argument vector.  */
    alloc_args ();
  
    obstack_init (&obstack);
  
Index: gcc/doc/invoke.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.356.2.18
diff -c -5 -p -r1.356.2.18 invoke.texi
*** gcc/doc/invoke.texi	27 Jul 2005 20:27:16 -0000	1.356.2.18
--- gcc/doc/invoke.texi	25 Aug 2005 03:31:49 -0000
*************** in the following sections.
*** 154,164 ****
  
  @table @emph
  @item Overall Options
  @xref{Overall Options,,Options Controlling the Kind of Output}.
  @gccoptlist{-c  -S  -E  -o @var{file}  -pipe  -pass-exit-codes  @gol
! -x @var{language}  -v  -###  --help  --target-help  --version}
  
  @item C Language Options
  @xref{C Dialect Options,,Options Controlling C Dialect}.
  @gccoptlist{-ansi  -std=@var{standard}  -aux-info @var{filename} @gol
  -fno-asm  -fno-builtin  -fno-builtin-@var{function} @gol
--- 154,164 ----
  
  @table @emph
  @item Overall Options
  @xref{Overall Options,,Options Controlling the Kind of Output}.
  @gccoptlist{-c  -S  -E  -o @var{file}  -pipe  -pass-exit-codes  @gol
! -x @var{language}  -v  -###  --help  --target-help  --version @@@var{file} }
  
  @item C Language Options
  @xref{C Dialect Options,,Options Controlling C Dialect}.
  @gccoptlist{-ansi  -std=@var{standard}  -aux-info @var{filename} @gol
  -fno-asm  -fno-builtin  -fno-builtin-@var{function} @gol
*************** Print (on the standard output) a descrip
*** 931,940 ****
--- 931,948 ----
  line options for each tool.
  
  @item --version
  @opindex version
  Display the version number and copyrights of the invoked GCC.
+ 
+ @item @@@var{file}
+ @opindex @@
+ Read command-line options from @var{file}.  The content of the
+ @var{file} is separated into whitespace-separated strings.  Each
+ string is treated as a command-line option.  The options read from the
+ file are inserted in place of the @@@var{file} option.
+ 
  @end table
  
  @node Invoking G++
  @section Compiling C++ Programs