rfc: __builtin_types_compatible_p and unsigned literals

rfc: __builtin_types_compatible_p and unsigned literals

[Aldy Hernandez]

hi guys.

we all agree, this should return true:

	__builtin_types_compatible_p (unsigned int, 31U)

but how about this:

	__builtin_types_compatible_p (unsigned int, 31)  /* signed literal */

this last one currently returns false, but in the spirit of C, i think
it should return true.

for example,

	int foo (unsigned int blah) { }

accepts foo(31) as well as foo(31U).

can i "fix" __builtin_types_compatible_p?

aldy

Re: rfc: __builtin_types_compatible_p and unsigned literals

[Joseph S. Myers]

On Mon, 6 May 2002, Aldy Hernandez wrote:

> for example,
> 
> 	int foo (unsigned int blah) { }
> 
> accepts foo(31) as well as foo(31U).

It also accepts foo(31LL) and other such implicitly convertible types, if
the prototype is in scope.  Or are you referring to the special case where
a prototype isn't in scope (and for variable arguments), and
signed/unsigned can be mixed provided the value is representable in both
types?

> can i "fix" __builtin_types_compatible_p?

The types aren't compatible.  (Pointers to them aren't even implictly
convertible, though you'll need -pedantic to get a warning about that.)  
Making the specification more complicated and less representative of the
name of the built-in function seems dubious.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: rfc: __builtin_types_compatible_p and unsigned literals

[Aldy Hernandez]

On Mon, May 06, 2002 at 10:42:08AM +0100, Joseph S. Myers wrote:
> On Mon, 6 May 2002, Aldy Hernandez wrote:
> 
> > for example,
> > 
> > 	int foo (unsigned int blah) { }
> > 
> > accepts foo(31) as well as foo(31U).
> 
> It also accepts foo(31LL) and other such implicitly convertible types, if
> the prototype is in scope.  Or are you referring to the special case where
> a prototype isn't in scope (and for variable arguments), and
> signed/unsigned can be mixed provided the value is representable in both
> types?

i'm not sure i follow you.

what i'm referring to, is that i believe the following should all
return true:

	__builtin_types_compatible_p(int, typeof(1))
	__builtin_types_compatible_p(int, typeof(1L))
	__builtin_types_compatible_p(int, typeof(1LL))
	__builtin_types_compatible_p(int, typeof(1U))
	__builtin_types_compatible_p(int, typeof(1ULL))
	__builtin_types_compatible_p(int, typeof(1UL))
	etc

whereas now, these  return false.  they should return true-- after all,
they are *compatible*.

> > can i "fix" __builtin_types_compatible_p?
> 
> The types aren't compatible.  (Pointers to them aren't even implictly
> convertible, though you'll need -pedantic to get a warning about that.)  

perhaps we should return true, like i suggest, but warn with -pedantic??

aldy

Re: rfc: __builtin_types_compatible_p and unsigned literals

[Joseph S. Myers]

On Mon, 6 May 2002, Aldy Hernandez wrote:

> what i'm referring to, is that i believe the following should all
> return true:
> 
> 	__builtin_types_compatible_p(int, typeof(1))
> 	__builtin_types_compatible_p(int, typeof(1L))
> 	__builtin_types_compatible_p(int, typeof(1LL))
> 	__builtin_types_compatible_p(int, typeof(1U))
> 	__builtin_types_compatible_p(int, typeof(1ULL))
> 	__builtin_types_compatible_p(int, typeof(1UL))
> 	etc
> 
> whereas now, these  return false.  they should return true-- after all,
> they are *compatible*.

They're not compatible.  Compatibility is defined in C99 subclause 6.2.7.  
They can be implicitly converted in a function call, by 6.5.2.2#2, but 
that's because one of the circumstances listed in 6.5.16.1#1 (which are 
asymmetric - you can assign char * to const char * but not the other way 
round - whereas compatibility is symmetric) applies.

float, double and long double are all incompatible - and all need to be
distinguished for <tgmath.h> and such purposes for which
__builtin_types_compatible_p was designed - though they can be assigned to
each other.

-- 
Joseph S. Myers
jsm28@cam.ac.uk