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:
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 serious
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
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.
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-file
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't it?
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 Richard
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 being documented.
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
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 wider scope
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:
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
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
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
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
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
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 (normally
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
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 Windows
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: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, ...).
Yes
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
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
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?
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
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
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
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.
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
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
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!
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
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 interpretation of
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 programs will never
* 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 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
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
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
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 command-line
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
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:
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.
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 argument to a
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
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
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
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
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
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
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
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
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
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 command-line
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.
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.
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
56 matches
Mail list logo
