[egcs 1.1] Fix gcc.c handling of %O vis-a-vis temp files

[Jeffrey A Law]

  In message < 199807271622.MAA08460@melange.gnu.org >you write:
  > >This is the desired behavior now.  Each time you compile a file you 
  > >use a new set of temporary files.
  > 
  > There's not quite enough detail in what you wrote for me to be *sure*
  > what you're saying, but I believe the canonical interpretation would be
  > incorrect for the current sources.  You might use a new *set* for
  > the entire compile, but you still use a *single* file for the output
  > from the preprocessor and the input to the compiler; for the output
  > of the compiler and the input to the assembler; and for the output
  > of the assembler and the input to the linker.  Right?
Right.

  > If not, pretty
  > much nothing would work -- right?  If so, and if, as I believe, the
  > *suffix* is the key for determining whether a previously generated
  > name is used, then `%O' is, as documented, just another suffix, right?
  > So it, too, should represent a *single* file each time `%g%O' is
  > specified, right?
OK.  I think I misunderstood your problem.

  > Originally, given `gcc foo.c', you got *one* temp filename "base" (sans
  > extension) for the preprocessed file, the assembler file, and the object
  > file.  Extensions were just "tacked on" to the `%g' or similar
  > specification.
Right.  This is unsecure and has been abandoned.

  > Currently, you get one temp filename *per extension*.  That is, you
  > get one temp filename for the preprocessed file; a different one for
  > the assembler file; and yet a different one for the object file.
Right.

  > The bug I'm fixing is that the handling of `%g%O' is broken.  It is
  > *supposed* to be exactly as if the proper target-specific suffix
  > (normally `.o') is present, as in `%g.o'.  But, unlike when `.o' is
  > explicitly used, do_spec_1 currently generates a *new* filename per
  > *occurrence* of `%g%O' in the specs it is processing.
OK.  Is it %g or %O that is causing us to create a new filename?

I won't claim to understand all the spec junk.  It's a horribly ugly
mess.  The explaination in this message has helped me much more than
your previous message in understanding the problem.  When submitters
fail to explain patches, it's quite likely I'll mis-understand the
problem being solved -- I don't know everything about the compiler.


I would claim that using %g is a bad thing because it creates easily
predictable names (since it's supposed to be choosen once per
compilation) which leads to a denial of service attack.

We should be moving away from using %g, which I guess was the ultimate
point of my previous message.  Why are you using %g?

[ Note this is separate from whether or not %g correctly implements
  its documented behavior, which I presume it does not, unless it
  is %O that is causing us to create a new temporary.  ]

  > Note that normal gcc and other `specs' entries don't really represent
  > linking of the object file using the "direct" approach -- essentially,
  > an exceptional mechanism is used to get the desired behavior, one that
  > I don't think g77 can use for `g77 -v', and perhaps one other front ends
  > can't always use.  (I believe I tried using this mechanism way back when
  > I was trying to get `g77 -v' to work for 0.5.23, and couldn't; certainly
  > gcc's exceptional handling of the linking phase isn't set up to *run* the
  > executable after linking it, so the gcc approach doesn't work, while
  > the approach g77 uses currently works fine, modulo newly introduced
  > bugs like this.)
Can you give more details why you can't use the existing link mechanisms?  
Maybe that is the core issue -- g77 is doing something "different" from
what most front-ends do, and as a result we seem to run into lots of
problems (particularly with -v).

  > P.S. Why do I feel I'm having to defend the workability of `g77 -v'
  > every couple of weeks?  Couldn't we just decide "it works, it's
  > useful, g77 users and developers have been depending on it for a
  > couple of years, so anything that breaks will be *assumed* to be
  > broken until proven otherwise"?
Please don't look at things this way.

Just because it's the way g77 has done things for years and its the way
g77 is documented does not make it right.  gcc has had conventions in
use for much longer and for the sake of consistency those conventions
should be used in all the languages.  Deviating from those conventions
for any language should not be taken lightly -- even if it's the way
that language has worked in the past.

This is part of the price of moving from a separate add-on language
to being part of the main distribution -- you have to conform to existing
practice more :-)

Note that the same applies to gcc itself, but to a lessor extent since
it defines the conventions.  In some cases we may choose to move towards
a different convention found in one of the languages because it is better
than existing conventions (ie g77 -v).

jeff