Re: pointer arithmetics and casts

[Al Viro <viro@ftp.linux.org.uk>]

On Fri, May 25, 2007 at 11:00:51PM +0100, Al Viro wrote:
> > But that means a fsckload of extra nodes allocated on pretty much any
> > program - use of arrays is not rare and indices tend to be int, so we
> > hit an extra allocated node on each such place.
> 
> Argh...  Question: how much do we care if we see BINOP[+] with 64bit
> type as result and 32bit type in one of the arguments?  That's what
> we get when we have
> 	char *p;
> 	int i;
> 
> 	p + i
> 
> with -m64.  IOW, how much does it violate the assumptions outside of
> frontend?  We do not allocate any new nodes if sizeof(*p) is 1...

Actually, turns out that at least on the kernel builds a straightforward
variant (IMPLIED_CAST when width of i is smaller than bits_in_pointer,
whatever sizeof(*p) might be) isn't visibly smaller...  It would need
more profiling, but there's a chance that nothing trickier would be
needed.

BTW, _Bool is seriously mishandled - for one thing, some places treat it 
as one-bit unsigned integer (i.e. (_Bool)2 becomes 0 with a warning, while
it should yield 1).  For another, sizeof(_Bool) becomes 0, with all obvious
breakage.  And finally, assignment of pointer to _Bool generates a warning
and cast.1 in linearizer.  Correct behaviour is (a) no warning whatsoever
and (b) replacement with b = (p != NULL).  The same thing applies in
passing arguments and in return statement, of course...

Oh, and type of comparison result is int, not _Bool...  It rarely matters,
but sometimes it does - e.g. sizeof(0 == 0) should evaluate to sizeof(int),
not sizeof(_Bool) (which basically casts the damn thing in stone - changing
the type of == result on valid C90 arguments would break existing programs).

I agree that use of bool_ctype in evaluate_compare() is very natural, but
we should at least take care interaction with sizeof ;-/