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