unexpected conversion (feature or bug?)

[Laszlo Ladanyi]

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.

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.

I'm sorry to say, but your advice is almost equivalent to the infamous RTFM
reply that's so frowned upon in every newsgroup. Typing in a book title
couldn't have taken much longer than this vague reply. I'm sure you know a
couple of books that has this sort of info, but even if you are not sure, you
can say that try this book or that.

--Laci


On Mon, 16 Aug 1999, Jeffrey A Law wrote:

>   In message < Pine.A41.4.05.9908161430570.28152-100000@oslpp.watson.ibm.com >you
>  write:
>   > Hello,
>   > 
>   > I think I've found something in the current gcc that is an unexpected
>   > behaviour. (It might be a feature :-). Here are the facts:
> [ ... ]
> I recommend you find out what the underlying type of a "size_t" is, then
> consult a good book about ANSI/ISO C.
> 
> jeff
> 
> 
>