Re: [Tinycc-devel] casting bug?

[Alexander Strasser]

Felix Nawothnig wrote:
> Alexander Strasser wrote:
> >>>Maybe it is really best to use special types like int_fast32_t
> >>>these times... (or role your own set of types to replace them
> >>>with the appropriate type depending on compiler and arch).
> >>There is no such thing as a fast 32bit integer on sane (read: non 
> >>x86-64) 64bit architectures.
> >Sorry, I don't get what you say here.
> >What I said was especially in regard to the decision of some
> >compilers to use the LP64 or LLP64 type models.
> 
> Sorry, I don't get what you mean here.

  communication breakdown :)

> We already have fixed size types like int32_t which are guaranteed to be 
> exactly 32bit wide, although using them might result in slow code if 
> they are not natively supported by the architecture.

  yes, this is not the problem i am talking about

> Then we have "int" which is at least 16bit wide and should be the native 
> register size (I dunno if the standard specifically says this but that's 
> the way it was before the (x86) empire), so should be the "fastest" type 
> (unless we talk about 8-bit CPUs for which ANSI C isn't really suited 
> anyway :)

  Ah back on topic, int isn't native register size on x86_64 anymore.
And this breaks the assumption (which is afaik not really guaranteed
by the standard) I and many others (including you) made.

> This is no longer true for many modern compilers due to zillions of 
> people who wrote unportable C - and this is the problem. It could have 
> been avoided maybe if fixed size types were introduced much earlier than 
> in 1999 (?) though...

  different discussion.

> You can't have both a guaranteed size and guaranteed performance (while 
> being portable), so what would your proposed "int_fast32_t" be then?

  It's not my proposed type, this exists already I don't know if it is
covered by C99 or not. But the trick would be let's say on a 64bit arch
and a compiler using LP64 model (int is normally 32bit in this case) you
would still get a 64bit integer. It is not about having fixed 32 bits
it is more about having a at least 32bit wide type.
  Well, of course it is not optimal if you target 16bit architectures in
that case you would have to use int_fast16_t.
  It's probably never really optimal, but it would be possible to use
practically at least. Best would be if the modern 64bit systems would
support for example the ILP64 model, and thus the good old int assumption
would still hold. But i think that train has already left and is far away...

  Alex (beastd)