unexpected conversion (feature or bug?)

[Geoff Keating]

Laszlo Ladanyi <ladanyi@watson.ibm.com> writes:

> As it happens I do know that the underlying size_t is `unsigned int'. That's
> why the conversion is needed. As I see it an int will be divided with an
> unsigned int. If you can recommend "a good book about ANSI/ISO C" that has the
> rules what sort of conversion must take place I would appreciate it. I do know
> that in general the conversion goes towards the higher precision, but honestly
> I don't see any difference in the precision of an int or an unsigned int. Only
> the range is shifted.

The ideal reference for this sort of thing is the ISO C standard,
which you can get from your friendly local standards body---in my case
http://www.standards.com.au .  It's 'ISO/IEC 9899:1990'.  The
conversion rules are documented in s. 6.2.1.5.

> Maybe I should have said that I know what size_t is, but even then
> it's not clear how (int)/(unsigned int) should be computed. And I
> did check a couple of books before sending in the report, but
> couldn't find this specific information in any of them.

The general rule is indeed that an expression is computed in the widest type
of the operands.  The order is:

long double;
double;
float;
unsigned long int;

then if one operand has type 'long int' and the other has 'unsigned int',
choose 'long int' if it can represent all 'unsigned int' values, and
'unsigned long int' otherwise;

long int;
unsigned int;
int;

In the next revision of the C standard, these rules are generalised
slightly; the types are ordered like this:

long double;
double;
float;
unsigned long long;  long long;
unsigned long int; long int;
unsigned int;  int;

and if you have an expression with an unsigned type and a signed type,
then you choose the signed type only if it is higher in the list and if
it can represent all the values of the unsigned type.

-- 
Geoffrey Keating <geoffk@cygnus.com>