> 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
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
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
> 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
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:
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
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
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
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
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
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
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'
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-
> 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
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
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
> 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
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
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
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
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
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
> 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.
> 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
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
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
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
> 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
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
* 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.
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
> "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
> 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/
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!
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
> 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
> 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".
> 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
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
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
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?
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
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
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, ...).
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
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
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
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
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
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
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
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
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
> 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.
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
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
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
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
58 matches
Mail list logo