This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] [PATCH] Implement -ffortify for C/C++
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Dirk Mueller <dmueller at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org, meissner at suse dot de
- Date: Tue, 30 Jan 2007 11:45:52 -0500
- Subject: Re: [RFC] [PATCH] Implement -ffortify for C/C++
- References: <200701301643.12230.dmueller@suse.de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jan 30, 2007 at 04:43:05PM +0100, Dirk Mueller wrote:
+@itemx -ffortify=@var{n}
+Instrument a set of string, memory and printf related functions into their
+_chk variants. @var{n} controls the behaviour in detail. A fortify level
+of 1 will produce compile warnings, but expand the _chk variants
+back into the non-checking equivalent, and therefore not introduce any
+run-time overhead in the generated code. A level of 2 will emit calls
+to the _chk variants if the overflow checking can only be done during
+runtime. Higher fortify levels are passed down to the printf related
+check functions and might control further fortify levels. A level of 0
+disables the instrumentation.
The description doesn't match what the patch is doing. It seems
the patch has similar (but not identical) meaning as the numbers
in -D_FORTIFY_SOURCE=, 1 being standard conforming checking,
2 adding further restrictions.
In glibc headers (as well as libssp headers) -D_FORTIFY_SOURCE=2
disallows str*/stp* etc. to cross structure field boundaries,
while mem* still can cross them, also %n in *printf is only supported
if format string is in read-only memory (string literal, _(string literal)).
With -D_FORTIFY_SOURCE=1 that's all allowed. In your patch
you handle mem* the same as str*/stp*.
Jakub