Jeremy Morse <[email protected]> wrote: > Perhaps we can also send this to some gcc developers and ask why gcc > didn't notice 'len' was being used uninitialized, or that an integer > was being passed as a pointer.
No, gcc is not guilty. Given typedef uint8_t uWord[2]; and uWord len; the following fragment of the diff: - err = uvideo_stream_probe(vs, UR_GET_LEN, len); + err = uvideo_stream_probe(vs, UR_GET_LEN, &len); is no-op, you pass exaclty same value for len and &len, so that was not what fixed the crash, the UGETW(len) <= sizeof(...) check did. PS: Extra credit for explaining the difference between len and &len in a context where void * doesn't muffle it up. PPS: Given these carefully laid-out set of rakes beautifully arranged in geometric patterns, gift-wrapped for extra touch and waiting for people to step on them, I would seriosly suggest to introduce request-specific inline functions that *do* type-check what is now the "void * data" argument. -uwe
