- args->endp - args->begin_argv + consume);
+ args->endp - (args->begin_argv + consume));
tbh I've considered simply banning math-operator-precedence in projects I work on, and requiring all mixed-operator code to use parenthesis or split to multiple statements. I do that myself, at least.I've seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it really doesn't seem worth it (in most code) for the extremely minor character savings.
- and + operators have the same precedence. And a similar bug is possible if the operators were the same (both -). So I’m not sure it’s right to blame this on operator precedence or mixed operators. It’s just that, ultimately, the “consume” needs to be subtracted, not added.
Smalltalk didn't have math operator precedence, and I thought it was very annoying but I've come to believe it was a good idea.
That's what pony did also. Operator preceding rules are too arcane, such as the need for manual memory management.
IIRC several industry and government coding standards don't permit evaluations in arguments to functions, as the compiler can end up doing wonky things, to say nothing of the likely human error. These are the kind of standards we should be adapting into a software building code to avoid security holes like this one.
I think I’d generalize that rule to require parentheses in any situation where adding parentheses could change the interpretation. I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.
is order dependent, even if its deterministic and knowable. When I’m scanning the code to look for a pesky bug, I don’t wanna have to take extra seconds to convince myself that it’s doing what I expect. It steals time and my limited attention from more interesting sections of code.