i could have made this longer but i have a feeling it might be more powerful in this form.
there is no programming construct that offers more freedom and flexibility than GOTO. consequently, no programming construct carries with it a greater potential for complexity.
since "complexity is the worst enemy of security", therefore GOTO should be considered harmful to and/or an enemy of security.
i'm surprised more people haven't made this connection, or that it hasn't seen more mainstream attention. whatever else you may think of GOTO in regular software, in security-related software this has to be an added consideration. the traditional taboos against GOTO that Larry Seltzer identified may not be entirely rational, but i tend to think the security taboo against complexity is.
2 comments:
Do you mean goto in the generic sense of an unconditional jump or literally the keyword goto?
do
{
int rv = something();
if (!rv)
{
/* GOTO */
break;
}
something_else();
} while(0)
int some_function()
{
int rv = something();
if (!rv)
{
/* effectively a goto */
return 0;
}
return something_important();
}
Harping on the goto keyword is pretty pointless, really the culpret is control flow semantics that skip very important behavior.
@Matt Boney:
i do in fact mean literally the keyword GOTO. i'm aware that RETURN and BREAK are related to GOTO, but they are much more constrained than GOTO. for example, neither RETURN nor BREAK can jump to a point in the code preceding themselves. the constraints on RETURN and BREAK reduce the amount of complexity using them can add.
while i'd certainly agree that skipping important behaviour is bad, that is something that can be done with all kinds of statements. even getting the conditional expression in an IF statement wrong can lead to that.
Post a Comment