From: Jakub Jelinek <jakub@redhat.com>
>On Thu, Jan 06, 2000 at 08:53:23PM -0500, Johan Kullstam wrote:
>> Thierry Vignaud <tvignaud@mandrakesoft.com> writes:
>>
>> > Jesse Pollard a écrit :
>> > >
>> > > Johan Kullstam" <kullstam@ne.mediaone.net>
>> > > >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.
>> >
>> > ever head of inttypes.h ???
>>
>> consider a 64 bit processor where you'd like to have 64 bit integers.
>> use the following:
>>
>> type bits
>> char 8
>> short int 16
>> int 64
>> long int 64
>> long long 128
>>
>> ok now that we have no 32 bit integer quantity, please get me a 32 bit
>> integer using a #define macro.
>
>Its up to stdint.h to provide you correct typedefs for int8_t, int16_t,
>int32_t, int64_t. E.g. with gcc, it is easy,
>e.g. on archs with char type 8bit large with
>typedef int int32_t __attribute__((mode (SI)));
>even if int is 64bit as well as long,
>and I think other compilers have their ways of doing something similar as
>well.
>128bit long long is very uncommon these days on the other side, even on
>64bit architectures.
Oh, I don't know about that -- I can think of several applications that
use up to 4096 bit integers. How about SSL, PGP, IP v 6 addresses are 128 bit,
IPSec might use "long" ints. DES could use 56 bit integers. Right now these
applications do all of the arithmetic in C library functions that define
the arithemtic. Wouldn't it be more efficient if it could be implemented
directly in the language?
My reply was addressing the need for variable length integers not necessarily
supported in hardware available sizes. No header may define an int larger
than that supported by hardware (the "sizeof(int)" thing), without a
nonstandard C compiler. The bitfield syntax appeared to fit the bill with
a minimum of alteration in the grammar or symantic alterations.
Such a construct would allow integers on any sized platform for source
code compatability. It requires the compiler/runtime system to generate
the appropriate operations to support the language.
<rant on>
I realize this is an off-topic reply, but the entire thread appeared to be
off-topic, since POSIX defines what the size of time_t is going to be.
One UNIX system I have used had ints limited to 16 bits. Guess what- time_t was
defined as:
typedef int time_t[2];
Is this an accepable substitute? not really, but it worked. Could date
arithmetic be done easily? no. It was all nonstandard, calling assembly
library functions to perform the arithemtic (add, sub, mul, div, test).
All that was required was that it work.
<rant off :)>
I do think that an addition to the compiler (nonstandard of course) that
allowed integers to be defined as "int var : 36;" would be very usefull,
and may solve many related problems. I haven't addressed the use of
constants here... (um, how about ddddddddddddd:ddB form where d is a digit,
:dd is the length, and B is a base indicator - H for hex digits, D for
decimal)
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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:09 EST