On Tue, Mar 10, 2015 at 10:24 AM, Michael Kerrisk (man-pages) <mtk.manpages@xxxxxxxxx> wrote: > Hi Kees, > > I was looking further at the seccomp(2) man page we put togetehr a > while ago, and in particular at the example [1]. I realized that from > a readability view, the order of the statements is rather contorted, > so that we have branches to the end of the code (labels 5 and 6) to > handle the syscall and arch mismatch cases, rather than swapping the > branch order on the statements labeled 0 and 1, and having the kill > statements immediately follow the test statements. > > However, I presume the ordering is as it is for efficiency reasons, so > that the common case involves no branch forward (i.e., a branch offset > of 0). Is that the case? If so, probably something should be said in > the man page. I've never attempting timing tests to see if branching in the common path is actually any more expensive, but it's not unreasonable. I think the main reason it was written this way was actually for size. There's 1 kill statement, which avoids repeating it, and (I think) is more readable. Ultimately, it's really up to the author of the filter to do what they want, but there wasn't a specific speed efficiency goal with how it was written. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
