[RFC] explicitly signed and friends

[RFC] explicitly signed and friends

[Al Viro]

	Observations:
1)
	signed int x;
	typedef typeof(x) A;
	struct {
		A x:2;
	};
and
	typedef signed int A;
	struct {
		A x:2;
	};
give different results; the latter is explicitly signed, the former isn't.

2)
	typedef typeof(signed int) A;
	struct {
		A x:2;
	};
doesn't give explicitly signed.

IOW, it looks like gcc turns signed int/long/long long into corresponding
types in all contexts other than bitfield declaration and typedef.  I.e.
it's dealt with in declaration parser; for typedef and bitfield it becomes
a flag of symbol, not a part of type.

3)
In ?: we _can't_ ignore the difference between int * and unsigned *; after
all, in *(n ? p : q) < 0 we want to know whether we get pointer to signed
or pointer to unsigned out of ?:.  IOW, in that context sparse should
scream bloody murder, -Wtypesign or not.  FWIW, gcc recovers in that
case with converting both arguments to void *; as long as we only care
about the address it's OK, but we've lost all information about the
type of object sitting there.

4)
gcc is kinda-sorta tolerant to mixing pointers to signed and unsigned,
unless you explicitly ask to be strict.  However, it's nowhere near
as lenient as sparse.
	* pointer comparison warns, even in absense of any -W...
	* only assignment and equivalents (passing argument, return,
initializer) remains silent and only when we mix pointer to unsigned
with pointer to signed variant of the same.
	* pointer to function returning signed and poitner to function
returning unsigned do not mix (i.e. you always get a warning).
	* pointer to pointer to signed doesn't mix with pointer to pointer
to unsigned.
	* pointer to function with pointer to signed as argument doesn't
mix with pointer to function with pointer to unsigned as argument.
IOW, this stuff should be special-cased in compatible_assignment_types(),
not in type_difference().
	* pointer subtraction even between unsigned * and int * is
a flat-out error.  Even for char *, signed char * and unsigned char *,
in any combination.

It makes sense, actually; being lenient about passing arguments is one
thing, but when it comes to things like pointer subtraction all reasons
for that kind of forgiveness disappear.

IMO we should
	a) get rid of sint_ctype and friends.
	b) when we find MOD_EXPLICITLY_SIGNED in declaration, check
that it's typedef or bitfield and that we have no pointer/array/function
declarators in there.  For typedef set it in resulting SYM_NODE
modifiers, for bitfield use it in choosing MOD_SIGNED or MOD_UNSIGNED.
Normal logics for declaration parsing will have it picked from typedef
to typedef and from typedef to bitfield.
	c) unroll one level of type_difference() for pointers in
compatible_assignment_types().  We need special handling of null pointer
constants and void * there anyway; might as well do handling of !Wtypesign
in there.  type_difference() would be called for base types.

After that we can get rid of most of the odd logics in type_difference(),
so there's even a chance to get __builtin_same_type_p() working correctly...

Comments?

Re: [RFC] explicitly signed and friends

[Derek M Jones]

Al,

> 4)
> gcc is kinda-sorta tolerant to mixing pointers to signed and unsigned,
> unless you explicitly ask to be strict.  However, it's nowhere near
> as lenient as sparse.

Values wrapping because of signed/unsigned is a common cause of
faults.  In those contexts where the pointer is eventually dereferenced
to obtain a pointer I think sparse should continue to complain.

Differences of sign in pointer subtraction may or may not be regarded as
harmless.

I appreciate that gcc is currently an important compiler.  But I
know of several compiler groups who would like to be able to build
an executable kernel using their compiler.  Having sparse complain about
constructs that gcc is rather lax about means that those involved in
kernel development might fix the underlying problem in their code.
Such fixes are good in that they increase the probability that a
different compiler will successfully compile the kernel.  I think a
bit of competition in the kernel compiler market would help keep the
gcc people on their toes.

-- 
Derek M. Jones                              tel: +44 (0) 1252 520 667
Knowledge Software Ltd                      mailto:derek@knosof.co.uk
Applications Standards Conformance Testing    http://www.knosof.co.uk

Re: [RFC] explicitly signed and friends

[Al Viro]

On Tue, Jul 03, 2007 at 04:38:49PM +0100, Derek M Jones wrote:
> Al,
> 
> >4)
> >gcc is kinda-sorta tolerant to mixing pointers to signed and unsigned,
> >unless you explicitly ask to be strict.  However, it's nowhere near
> >as lenient as sparse.

> Having sparse complain about
> constructs that gcc is rather lax about means that those involved in
> kernel development might fix the underlying problem in their code.

Compare the last two sentences...

Re: [RFC] explicitly signed and friends

[Derek M Jones]

Al,

>>> 4)
>>> gcc is kinda-sorta tolerant to mixing pointers to signed and unsigned,
>>> unless you explicitly ask to be strict.  However, it's nowhere near
>>> as lenient as sparse.
> 
>> Having sparse complain about
>> constructs that gcc is rather lax about means that those involved in
>> kernel development might fix the underlying problem in their code.
> 
> Compare the last two sentences...

I was running in Dr Who mode.

-- 
Derek M. Jones                              tel: +44 (0) 1252 520 667
Knowledge Software Ltd                      mailto:derek@knosof.co.uk
Applications Standards Conformance Testing    http://www.knosof.co.uk