This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] PR16118: Users complaining about the proofing.


GCC is remarkably tolerant of users doing silly things.  One example is
the potential adverse interaction between the command line options "-x"
and "-save-temps".  The "-x" (a.k.a. "--language") compiler option
disables/overrides GCC's default file typing based upon filename
extension.  This allows the user to use arbitrary file extensions
"x.foo", or even (mis)use "conventional" file extensions for other
formats, i.e. using "foo.s" as a C or C++ source code.

Abuse of this latter feature and GGC's "-save-temps" option would appear
to be asking for trouble.  When processing a C source file that would
normally generate intermediate files named "foo.i" and "foo.s", using
either filename as the input source file should perhaps strike most people
as potentially risky :>.

GCC, of course, has been idiot-proofed (or more appropriately
user-proofed) to prevent this kind of accidental over writing of the
user's source files.  It detects that the intermediate file would have
the same name as the input file, and instead of failing, completes
the compilation by using a temporary file in /tmp instead (as it would
without -save-temps).

PR driver/16118 concerns a complaint that when doing something this
"bizarre", that GCC doesn't preserve the intermediate file with the
same name as the source file!?  IMHO, GCC has already gone "beyond the
call of duty" by compiling the file in such a hostile environment,
and (i) not over writing the user's source file and (ii) cleaning
up uniquely named temporary files in shared system temporary directories
would appear to be the Right Thing To Do.  At the very least, this PR
should be downgraded from a "normal bug" to a "low priority enhancement
request" (though NOT-A-BUG or WONT-FIX seem more appropriate).

However, in the submitter's defense, we currently don't document the
potential interaction between "-save-temps" and "-x".  If someone doesn't
appreciate the potential "hazard" of using -save-temps whilst abusing
intermediate file naming conventions, GCC's "evasive manoeuvring" may
seem/appear counter-intuitive.

The documentation patch below describes the potential interaction
between -x and -save-temps, and the necessary work-around to achieve
the desired results.


Ok for mainline?  Does anyone disagree and think this is a real bug?
We can't/shouldn't reuse an "obvious" name for a temporary file, such
as "foo.s" in /tmp, to avoid unintentional clashes and denial of service
attacks.  Indeed, if we knew of a deterministic filename to use, we'd
place it in the current/source directory.  Perhaps "-save-temps -pedantic"
should fail if an intermediate file would over-write the input file??

Either way, documenting GCC's current behaviour can't hurt.



2004-12-27  Roger Sayle  <roger@eyesopen.com>

	PR driver/16118
	* doc/invoke.texi: Document the interaction between -save-temps
	and -x.


Index: invoke.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.562
diff -c -3 -p -r1.562 invoke.texi
*** invoke.texi	18 Dec 2004 20:22:52 -0000	1.562
--- invoke.texi	28 Dec 2004 01:29:30 -0000
*************** compiling @file{foo.c} with @samp{-c -sa
*** 3891,3896 ****
--- 3891,3902 ----
  preprocessed @file{foo.i} output file even though the compiler now
  normally uses an integrated preprocessor.

+ When used in combination with the @option{-x} command line option,
+ @option{-save-temps} is sensible enough to avoid over writing an
+ input source file with the same extension as an intermediate file.
+ The corresponding intermediate file may be obtained by renaming the
+ source file before using @option{-save-temps}.
+
  @item -time
  @opindex time
  Report the CPU time taken by each subprocess in the compilation


Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]