4 ms·
I see a lot of comments to the effect of "shouldn't XYZ also be banned". The answer is that we're not necessarily trying to be exhaustive. The point is to flag
by peff 7y ago
I see a lot of comments to the effect of "shouldn't XYZ also be banned". The answer is that we're not necessarily trying to be exhaustive. The point is to flag common errors before we even hit review, so we add new functions mostly when somebody tries to misuse them. I don't recall anybody trying to abuse longjmp() in Git's codebase yet (and no, that's not a challenge).
- Cogito 7y agoPeff, for the people asking in the thread, is there a place where correct alternatives are suggested or demonstrated? I know there are a few different places that talk about how to use git's internal machinery, but not sure if any are specific to these banned functions.
- masklinn 7y agoThe original commits mentions git's strbuf API[0] and its xsnprintf, a variant of snprintf which asserts that the destination buffer was big enough[1] (rather than just return truncation information). For other codebases, snprintf is the usual recommendation, and careful straight buffer manipulation (mem*) iff performances are a concern. [0] https://schacon.github.io/git/technical/api-strbuf.html https://schacon.github.io/git/technical/api-strbuf.html [1] https://code.forksand.com/linux/git_git/commit/7b03c89ebd10396ac7569f0c8c4fa0b4efd4f7ed https://code.forksand.com/linux/git_git/commit/7b03c89ebd103...
- peff 7y agoThe commit messages that add them to banned.h discuss alternatives, though most of the explanations are Git-specific and assume you'll look elsewhere to figure out how to actually use those alternatives.