Re: 4.2 Project: "@file" support

2005-08-30 Thread 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

Re: 4.2 Project: "@file" support

2005-08-27 Thread Alexandre Oliva
On Aug 25, 2005, DJ Delorie <[EMAIL PROTECTED]> 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

Re: 4.2 Project: "@file" support

2005-08-26 Thread 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

Re: 4.2 Project: "@file" support

2005-08-26 Thread 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-d

Re: 4.2 Project: "@file" support

2005-08-26 Thread 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:

Re: 4.2 Project: "@file" support

2005-08-26 Thread Russ Allbery
DJ Delorie <[EMAIL PROTECTED]> 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 wide

Re: 4.2 Project: "@file" support

2005-08-26 Thread 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

Re: 4.2 Project: "@file" support

2005-08-26 Thread 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 wi

Re: 4.2 Project: "@file" support

2005-08-26 Thread Laurent GUERBY
On Fri, 2005-08-26 at 10:21 -0700, Ian Lance Taylor wrote: > Sergei Organov <[EMAIL PROTECTED]> 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 bein

Re: 4.2 Project: "@file" support

2005-08-26 Thread Ian Lance Taylor
Sergei Organov <[EMAIL PROTECTED]> 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 R

Re: 4.2 Project: "@file" support

2005-08-26 Thread Sergei Organov
Ian Lance Taylor writes: > Sergei Organov <[EMAIL PROTECTED]> writes: > > > Laurent GUERBY <[EMAIL PROTECTED]> 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

Re: 4.2 Project: "@file" support

2005-08-26 Thread Ian Lance Taylor
Sergei Organov <[EMAIL PROTECTED]> writes: > Laurent GUERBY <[EMAIL PROTECTED]> 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'

Re: 4.2 Project: "@file" support

2005-08-26 Thread Sergei Organov
Laurent GUERBY <[EMAIL PROTECTED]> 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-

Re: 4.2 Project: "@file" support

2005-08-26 Thread 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 file

Re: 4.2 Project: "@file" support

2005-08-26 Thread 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

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 pr

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 fo

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 co

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 fro

Re: 4.2 Project: "@file" support

2005-08-25 Thread Daniel Jacobowitz
On Thu, Aug 25, 2005 at 10:27:12AM -0700, Ian Lance Taylor wrote: > Mark Mitchell <[EMAIL PROTECTED]> 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 arg

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

2005-08-25 Thread 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 thusl

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

Re: 4.2 Project: "@file" support

2005-08-25 Thread Ian Lance Taylor
Mark Mitchell <[EMAIL PROTECTED]> 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 comm

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

RE: 4.2 Project: "@file" support

2005-08-25 Thread 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 b

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

2005-08-25 Thread Ranjit Mathew
On 8/25/05, DJ Delorie <[EMAIL PROTECTED]> 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 pro

Re: 4.2 Project: "@file" support

2005-08-25 Thread Tom Tromey
> "Ranjit" == Ranjit Mathew <[EMAIL PROTECTED]> 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 inter

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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/

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

2005-08-25 Thread 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

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 alread

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

2005-08-25 Thread 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 ar

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 djg

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 tha

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

2005-08-25 Thread Robert Dewar
Andi Kleen wrote: Mark Mitchell <[EMAIL PROTECTED]> 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 fr

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 y

Re: 4.2 Project: "@file" support

2005-08-25 Thread Jan-Benedict Glaw
On Thu, 2005-08-25 12:49:16 +0200, Andi Kleen <[EMAIL PROTECTED]> 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, ...).

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

Re: 4.2 Project: "@file" support

2005-08-25 Thread Jan-Benedict Glaw
On Thu, 2005-08-25 12:31:34 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote: > Mark Mitchell <[EMAIL PROTECTED]> 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 W

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 ve

Re: 4.2 Project: "@file" support

2005-08-25 Thread Andi Kleen
Mark Mitchell <[EMAIL PROTECTED]> 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 (norm

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 t

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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

Re: 4.2 Project: "@file" support

2005-08-25 Thread 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 t

Re: 4.2 Project: "@file" support

2005-08-24 Thread 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

Re: 4.2 Project: "@file" support

2005-08-24 Thread 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. I

Re: 4.2 Project: "@file" support

2005-08-24 Thread 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

2005-08-24 Thread DJ Delorie
Mark Mitchell <[EMAIL PROTECTED]> 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 comm

Re: 4.2 Project: "@file" support

2005-08-24 Thread 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 r

Re: 4.2 Project: "@file" support

2005-08-24 Thread 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 conte

4.2 Project: "@file" support

2005-08-24 Thread 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-li