Bug 10961 - read_specs -- compilers[n_compilers].cpp_spec not initialized
Summary: read_specs -- compilers[n_compilers].cpp_spec not initialized
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 3.2.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
: 11017 (view as bug list)
Depends on:
Reported: 2003-05-23 23:18 UTC by David Taylor
Modified: 2007-01-17 18:39 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2005-11-21 05:26:17


Note You need to log in before you can comment on or make changes to this bug.
Description David Taylor 2003-05-23 23:18:05 UTC
In read_specs (gcc.c), there's the lines:

	  /* Add this pair to the vector.  */
	    = ((struct compiler *)
	       xrealloc (compilers,
			 (n_compilers + 2) * sizeof (struct compiler)));

	  compilers[n_compilers].suffix = suffix;
	  compilers[n_compilers].spec = spec;
	  memset (&compilers[n_compilers], 0, sizeof compilers[n_compilers]);

Now, compilers[n_compilers].cpp_spec is not initialized here.

Yes, most people don't define compilers in the specs file; and yes, there's
a chance that the memory returned by xrealloc might be freshly obtained from
the OS (and hence zero'ed for security reasons), but you can't count on
either of those.  It should be zero'ed.

The one line fix is obvious.

This bug is present in all versions from 3.2.3 onwards (and probably goes
back quite a ways).
Comment 1 Andrew Pinski 2003-05-28 16:03:04 UTC
*** Bug 11017 has been marked as a duplicate of this bug. ***
Comment 2 Andrew Pinski 2003-05-28 16:04:25 UTC
Please make a patch and post it to gcc-patches@gcc.gnu.org.
Read http://gcc.gnu.org/contribute.html for how to make the patch and such.
Comment 3 Dara Hazeghi 2003-06-16 18:25:55 UTC

would you mind commenting on whether this is still an issue, and whether the proposed fix is 
correct? Thanks,

Comment 4 Andrew Pinski 2003-06-30 14:12:25 UTC
Should not be in waiting.
Comment 5 Tom Tromey 2007-01-17 18:39:20 UTC
I read through the existing code here and I think it is subtly correct.

The default_compilers array has a final entry consisting of all zeroes:

  /* Mark end of table.  */
  {0, 0, 0, 0, 0}

'compilers' is initially a copy of this table.  So, the last entry in
compilers is all zeroes.

The code quoted in the PR is reallocating the compilers array.  It sets
some fields in the final entry -- but not all fields.  However, this is ok
since we know those to be zero.  Then this code memset()s the new
terminating entry to be all zeroes.  This lets us conclude that this
code is safe, by induction.

So, I am closing this PR as invalid.  If you believe this analysis is
in error, please reopen the PR and explain how.  I will provide a patch
in this case.