>>>>> Mark Immel <immel@chord.centerline.com> writes:

> Doesn't it seem that an unsigned short should be promoted to an unsigned
> int before a void*?

If an int is large enough to hold all values of unsigned short (UNIX),
unsigned short will promote to int; otherwise (DOS) it will promote to
unsigned int.

Yes, this makes it difficult to write portable code.

Jason

The ARM sp[ecifically states that the ambiguity of your
third case "bar((unsigned short) 0);" is implementation
dependent.

Conversions that are "integral promotions" are of
higher priority that other stnadard conversions. However,
it is implementation dependent as to whether the integral
promotion of unsigned short is to int or to unsigned int.

Because of this it is quite possible for the same
function to be standard conforming with one compiler
and syntactically incorrect with a different, also
standard conforming, compiler.

In article <JASON.94Jul1112224@deneb.cygnus.com> jason@cygnus.com (Jason Merrill) writes:
>>>>>> Mark Immel <immel@chord.centerline.com> writes:
>
>> Doesn't it seem that an unsigned short should be promoted to an unsigned
>> int before a void*?
>
>If an int is large enough to hold all values of unsigned short (UNIX),
>unsigned short will promote to int; otherwise (DOS) it will promote to
>unsigned int.
>
>Yes, this makes it difficult to write portable code.

 IMHO the cast itself should be banned. Such architecture
dependencies should be part of architecture specific libraries
(that is, no even in the Standard Library).

 32 bit address code simply should not compile
on 16 bit systems. (And vice versa). Thats not to say direct
access to addresses should not be available -- it should
but NOT in a portable format -- because any code using
such dependencies CANT be portable.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

C++ Gurus --

I've got a question about the standard's interpretation of overloading:

In the following code, everybody agrees the first call to bar() is
ambiguous -- 0 is also the NULL pointer.  And everyone agrees the last
one is unambiguous -- ((unsigned int) 0) matches unsigned int exactly.
Some compilers (but not Cfront) think that the second ((int) 0) is
ambiguous.  The WP seems to say that int -> unsigned int is a standard
conversion just like ((int) 0) -> void*.  But some compilers (again not
Cfront) seem to think that the third ((unsigned short) 0) is ambiguous.
Doesn't it seem that an unsigned short should be promoted to an unsigned
int before a void*?  The WP actually seems to imply that the call *IS*
ambiguous, but this is because the overloading rules use the rules for
arithmetic operations (like +) which may not really be the right thing
to use...

Thanks,

-- Mark Immel
   immel@centerline.com

void bar(unsigned int)
void bar(void*)

void main()
{
  bar(0);
  bar((int) 0);
  bar((unsigned short) 0);
  bar((unsigned int) 0);
}