Is the co-pilot itself performance-sensitive?

Posted Sep 22, 2024 22:43 UTC (Sun) by NYKevin (subscriber, #129325)
In reply to: Is the co-pilot itself performance-sensitive? by rweikusat2
Parent article: pcp: pmcd network daemon review (SUSE Security Team Blog)

One wonders whether a sufficiently aggressive compiler will decide to translate the "fixed" version into (something equivalent to) this:

if(vindex < 0 || (char *)&pdubuf[vindex] == pduend) {

As far as I can tell, that's a legal optimization under the as-if rule, since you're allowed to assume that we never construct a pointer more than one past the end (even if it is not dereferenced).

Of course, in order for that to happen, the compiler would have to know that pduend is the actual end of the array, and not just some random pointer within the array. Maybe the compiler they tested it on is not smart enough to figure that out yet, and this will bite us all again in a few more years. The compiler would also need to somehow conclude that == is faster than >=, which strikes me as unlikely, but it can sometimes be difficult to tell what the compiler will do with a given piece of code under multiple optimization passes.

(For those less familiar with C's arcane UB rules: &foo[bar] expands to &*(foo + bar), and the standard explicitly specifies that &* cancels out and no dereference takes place. So we can't remove the whole comparison entirely - it is legal to construct a pointer exactly one past the end with an expression like that, and so the compiler is required to emit code which at least checks for such a pointer.)

to post comments

Is the co-pilot itself performance-sensitive?

Posted Sep 22, 2024 22:45 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

> For those less familiar with C's arcane UB rules: &foo[bar] expands to &*(foo + bar), and the standard explicitly specifies that &* cancels out and no dereference takes place. So we can't remove the whole comparison entirely - it is legal to construct a pointer exactly one past the end with an expression like that, and so the compiler is required to emit code which at least checks for such a pointer.

Side note: If the compiler can prove that the pointer can't be exactly one past the end (e.g. if it can prove that vindex is odd and the array is of even length, or vice-versa), then it may indeed omit the entire check, which I suspect is where problems might plausibly arise.