On 5 Jan 2000, Johan Kullstam wrote:
> "Richard B. Johnson" <root@chaos.analogic.com> writes:
[SNIPPED]
>
> yes, even a lowly Z80 can handle 64 bit quantities.
>
> however, the real problem is all the fileformats (like tar) and fixed
> definition structures which will break. as with y2k, the problem
> wasn't in the cpu per se, but in the data storage.
>
> > Adding stuff to do 'long-long' operations on a 'long' machine will
> > just add wasted CPU cycles. I think you should leave it alone.
>
> i wish C would get a decent set of integer types. it was once enough
> but now it's no longer the case.
>
> it's silly that int is 32 bits on the alpha since int is supposed to
> be whatever comes natural to your cpu, but how else would you cover
> the range 8, 16, 32, 64 bits?
>
Well I think `size_t` is supposed to be, as you say, whatever is
natural, with `ssize_t` being the signed variant.
> if you try to make int be 64 bit, then long and long must
> also be 64 or more. you've got char and short left to cover the
> important 8, 16 and 32 bit cases and you are left short (no pun
> intended).
>
> i'd also like to see C types with *specified* bit widths, e.g.,
> int16, int32, uint8 &c. then you could write more portable code when
> you really need a certain number of bits like for CRC algorithms. in
> case of 36bit computing on a pdp-10 the compiler could at least
> complain about lack of 32 bit support (even if it would be easy to
> add) instead of silently failing.
>
Well this is usually done with macros now, see /usr/include/sys/types.h
so we do have int8_t, int16_t, and their `u_xxx` variations, etc.
Cheers,
Dick Johnson
Penguin : Linux version 2.3.35 on an i686 machine (400.59 BogoMips).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:04 EST