Frank Ch. Eigler wrote:
Mark Mitchell <[EMAIL PROTECTED]> 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
