Nate DeSimone wrote:
Phillip Susi wrote:
There is nothing inherently wrong with goto,
it's only bad when it
makes the code less readable. When used carefully, like in this case,
it creates code that is _more_ readable, not less, and that's clearly
a good thing. Also as I said before, the problem is not a lack of
SEH, as I believe that is now supported by gcc so we could use it, but
rather the problem is that virtually none of the NTAPI uses SEH. In
order for SEH to be beneficial, it's use has to be widespread.
Ok, yes I agree that lacking SEH, gotos definately are more elegant
solution than a bunch of nested if statements. However thinking forward
a little bit, I recall that the use of gotos in your code can introduce
security vunerabilities and that you have to be very careful whenever
you use a goto, since we want ReactOS to be a mainstream OS we better do
a better job with security than MS. So may I recommend that the final
error handling boilerplate be double checked so that you can't get it to
jump to anouther address in memory than the intended address.
Hmmm... I'm not sure I follow how gotos lead to security
vulnerabilities?
Remember, gotos are just a jmp opcode... if goto's lead to
security vulnerabilities, so do if statements. The code
generated by the compiler is littered with hidden 'goto'
statements. If an attacker can overwrite the gotos that
are spelled 'goto', he can overwrite the ones spelled 'while',
'if', 'break', 'do', 'for', function calls, function
returns,
etc., etc., etc.
I don't believe the use of 'goto' in and of itself poses any
increased security risk.
I would claim that unexercised code is one source of
bugs (including security vulnerabilities.)
Therefor if statements _do_ lead to security vulnerabilities.
In particular, error handling (which is classicly unexercised
code) leads to security vulnerabilities. But not handling errors
leads to even more security vulnerabilities, so what is a guy to do?
Thanks,
Joseph