RE: [RFC] Mitigating unexpected arithmetic overflow

[David Laight <David.Laight@ACULAB.COM>]

...
> I think that would be a completely different area that might be worth
> looking at: instrumenting implicit casts for "drops bits". I'm afraid
> that it's just *so* common than we might not be able to do that
> sanely.

Things like:
	buf[0] = val;
	buf[1] = val >>= 8;
	buf[2] = val >>= 8;
	buf[3] = val >>= 8;
for writing a value little-endian and potentially misaligned.
Really doesn't want any annotation.

I've also seen code like:
	buf[0] = (unsigned char)(val & 0xff);
not only ugly by it got compiled to:
	val &= 0xff // for the &
	val &= 0xff // for the cast
	byte write to memory.
Modern gcc doesn't do that, but...

There are some spurious casts that drop bits.
I found plenty of dubious min_t(u8/u16,...) examples.
(Well they are dubious, some are just a lot more dubious than others.)
The problem is that every one needs careful inspection just in case
the strange behaviour is required like min_t(u8, val - 1, lo_lim - 1)
which treats lo_lim of zero as 'not a limit' and I think was ok.

A slow, concerted effort to remove min_t() calls wouldn't be a bad thing.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)