This is the mail archive of the gcc@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]

Re: [PATCH][4.3] Deprecate -ftrapv


Hi -

On Sun, Mar 02, 2008 at 09:30:25AM -0500, Robert Dewar wrote:

> [...]  Safety-critical and security-critical software are two
> totally different concepts. Be careful not to confuse them. In
> safety-critical software, e.g. avionics system, it is not acceptable
> for the system to crash.  In this context, the metaphorical "better
> to die", becomes all too real!

(Off topic, but I'd expect that avionics software is engineered with
enough layers of protection, including catching traps, so that a
-ftrapv hit would not cause a deep impact.)


> [...] However, in practice, it is hard to imagine a
> security-critical piece of software that would not take equal care
> to avoid any possibility of exceptional conditions at run time.

Maybe, but we just don't live in that world.

> For general security issues, especially with type unsafe languages,
> anything you can do at run-time to increase type safety certainly
> helps. 

Right, but gcc's approach is unsympathetic.  With -fstrict-overflow
becoming default in the usual "-O2 -g" builds, latent signed-overflow
bugs might become even harder to find.  It's as if GCC is sending the
a message like "Security is your problem - we favour 100% Pure C
Code.".

> However, I would suspect that -ftrapv is likely to be viewed and
> used only as a debugging aid in C, rather than something you
> routinely deploy in delivered software to improve security.

I guess it depends on how robust (=> predictable to experts) the
mechanism becomes.  The glibc fortify widget (enabled by some robust
gcc extensions) has found lots of use.

- FChE


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