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


Frank Ch. Eigler wrote:
Mark Mitchell <mark@codesourcery.com> writes:

[...]  You seem to be focusing on making -ftrapv capture 100% of
overflows, so that people could depend on their programs crashing if
they had an overflow.  That might be useful in two circumstances:
(a) getting bugs out (though for an example like the one above, I
can well imagine many people not considering that a bug worth
fixing), and (b) in safety-critical situations where it's better to
die than do the wrong thing.

Are you including in "safety-critical" all the security-related software, where signed-overflow is a popular exploit? If so, you are undervaluing the "better to die than do the wrong thing" principle. (This has come up several times here in the past, but not recently AFAICT.)

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!

For security-critical software that is not safety-critical, e.g. a
banking terminal, it is indeed better to crash than to compromise
security.

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.

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

- FChE


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