Re: gcc stack-smashing protector (for gcc-3.2.1)

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Thu, 9 Jan 2003, Hiroaki Etoh wrote:

>  This patch introduces -fstack-protector option, which is a stack-smashing 
> protection mechanism to the latest release (3.2.1).

You keep sending versions of this patch to gcc-patches, but unless and
until you following the GNU Coding Standards and GCC Coding Conventions
you can't expect them to be effectively reviewed or applied to GCC.  If
you haven't read and carefully followed all of
<http://gcc.gnu.org/contribute.html>,
<http://www.gnu.org/prep/standards_toc.html> and
<http://gcc.gnu.org/codingconventions.html>, patches are likely just to be
ignored.

Start by reading all the comments in all the files.  Ensure they are
correct (not old incorrect ones copied from other source files, e.g. the
descriptions of what the source files do look like that), complete
sentences and proper English.  Add proper Texinfo documentation and
testcases, as required for all patches; a proposed feature can be reviewed
on the basis of a patch with just documentation and testcases, but not on
the basis of full code without docs and testcases.  Use the proper
ChangeLog style.  Avoid obsolete terms, such as "GNU CC".  Use a generic
name such as flag_stack_protection rather than one such as
flag_propolice_protection which looks more like a trademark.  Give a
proper general overview of what the feature does and how it compares with
other features, such as the various different bounded pointers
implementations developed for GCC (e.g. the one (-fmudflap) currently
under development in tree-ssa).  Avoid unnecessary #ifdef conditional
code.  You could also follow Geoff Keating's suggestion
<http://gcc.gnu.org/ml/gcc-patches/2000-11/msg00099.html> and submit a
patch that adds just the basic canary-word feature.  Note patches must be
against CVS mainline (or possibly another branch during Stage 3 of
development), not releases.

-- 
Joseph S. Myers
jsm28@cam.ac.uk