> 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)
