is "typedef int int;" illegal????

[Mark McIntyre]

Perhaps by adding Long or llong or Llong for 128 bit integers? Ugly

And delightful to pronounce for our welsh colleagues.

Personallu I suspect they'll have to redefine the language
drastically.
Mark McIntyre

 

[ena8t8si]

Couldn't it simply use the same rules as declarations do -- i.e. require
compatible types?

extern unsigned int myvar;
extern size_t myvar;

If a type is given two typedefs with compatible
but different types, which one do you use? If
we see

typedef int F(int g(), int h(int));

F *f1;

typedef int F(int g(void), int h());

F *f2;

what are the types of f1 and f2? Which type is used
can affect what values may be assigned, etc.

 

[Wojtek Lerch]

If a type is given two typedefs with compatible
but different types, which one do you use? If
we see

typedef int F(int g(), int h(int));

F *f1;

typedef int F(int g(void), int h());

F *f2;

what are the types of f1 and f2? Which type is used
can affect what values may be assigned, etc.

The composite type, just like for any other declaration.

 

[ena8t8si]

The composite type, just like for any other declaration.

The problem is the composite type isn't known when f1 is
declared. Any uses between f1's declaration and the second
definition of F would either have to use the first type or
require a second pass. Using the composite type for both
isn't how other declarations work either.

 

[jacob navia]

Jordan Abel a écrit :

lcc-win32 supports 128 bit integers. The type is named:

int128

Planned is support for 128 bit constants with [snip]

printf("%i128d",m);

How do you differentiate this from the valid standard format string
consisting of %i followed by the string "128d"? Maybe you should use
%I128d instead, like how microsoft does I64

good point!!!!

Thanks for this remark.

jacob

 

[Wojtek Lerch]

The problem is the composite type isn't known when f1 is
declared. Any uses between f1's declaration and the second
definition of F would either have to use the first type or
require a second pass. Using the composite type for both
isn't how other declarations work either.

Well, how do they work? If a regular identifier is declared twice, its type
between the declarations may be different from the type after the second
declaration:

int arr1[], arr2[];
// arr1 and arr2 have the same, incomplete type here
int arr1[6], arr2[8];
// arr1 and arr2 have different, complete types here

Why couldn't the same rule apply to typedefs?

 

[Keith Thompson]

lcc-win32 supports 128 bit integers. The type is named:

int128

Which infringes on the user namespace. Is it defined in a
system-specific header?

 

[Jordan Abel]

Which infringes on the user namespace. Is it defined in a
system-specific header?

probably should be something like __int128, typedef'd to int128_t in
stdint.h

 

[Arthur J. O'Dwyer]

That "long long" even exists is a travesty.

What are we going to do when 128-bit ints become common in another
couple decades? [...]
All we need are "int float" and "double int" and the entire C type
system will be perfect! </sarcasm>

So how would you improve it?

Perhaps by adding Long or llong or Llong for 128 bit integers? Ugly
but there's nothing that can be done. Calling a 128 bit integer as
long long long would be ridiculous.

Obviously, 128 bits should be "long longer", and 256 bits should be
"long longest". Then, of course, 512 bits would be "longer longest" and
1024 bits would be "longest longest." That would cover us for another
few decades, at least.

-Arthur
sees problems with this proposal, unfortunately

 

[Old Wolf]

Like

a = a;

it does nothing

That code does do something, if "a" is volatile.

 

[pete]

That code does do something, if "a" is volatile.

It's undefined if (a) is indeterminate.

 

[David R Tribble]

That "long long" even exists is a travesty.

What are we going to do when 128-bit ints become common in another couple
decades? Call them "long long long"? Or if we redefine "long long" to be
128-bit ints and "long" to be 64-bit ints, will a 32-bit int be a "short
long" or a "long short"? Maybe 32-bit ints will become "short" and 16-bit
ints will be a "long char" or "short short"? Or is a "short short" already
equal to a "char"?

All we need are "int float" and "double int" and the entire C type system
will be perfect! </sarcasm>

It's interesting to note that most implementations (all of them I've
ever seen, in fact) only provide three of the four standard int type
sizes, with two of the four being the same size. For example,
consider the following typical choices of type sizes for various
CPU word sizes:

word | char | short| int | long | long long
-----+------+------+------+------+----------
8 | 8 | 16* | 16* | 32 | 64
9 | 9 | 18* | 18* | 36 | 72
9 | 9 | 18 | 36* | 36* | 72
12 | 8 | 24* | 24* | 48 | 96
16 | 8 | 16* | 16* | 32 | 64
16 | 8 | 16 | 32* | 32* | 64
18 | 9 | 18* | 18* | 36 | 72
18 | 9 | 18 | 36* | 36* | 72
20 | 10 | 20* | 20* | 40 | 80
24 | 8 | 24* | 24* | 48 | 96
32 | 8 | 16 | 32* | 32* | 64
36 | 9 | 18 | 36* | 36* | 72
40 | 8 | 20 | 40* | 40* | 80
60 | 10 | 30 | 60* | 60* | 120
64 | 8 | 16 | 32 | 64* | 64*
64 | 8 | 16 | 64* | 64* | 128

I've marked the duplicate type sizes in each row. Notice
that every row has two types of the same size.

So it's tempting to conclude that adding another int type
size to C would simply force compiler writers to provide
four actually different int sizes instead of only three.


Personally, I don't think we'll ever see 128-bit ints
as a standard C datatype, or to put it another way,
I don't think we'll ever see four standard int sizes in C.

But *if* that ever does happen, we'll simply call them
int128_t, etc., since C99 already has those types.

-drt

 

[Eric Sosman]

David R Tribble wrote On 03/27/06 11:44,:

It's interesting to note that most implementations (all of them I've
ever seen, in fact) only provide three of the four standard int type
sizes, with two of the four being the same size. [...]

In a 64-bit program for SPARC there are four different
integer widths: 8-bit char, 16-bit short, 32-bit int, and
64-bit long and long long.

My (possibly faulty) recollection has it that the DEC
Alpha used the same arrangement (without "long long") in
its compilers for OSF/1.

 

[David R Tribble]

It's interesting to note that most implementations (all of them I've
ever seen, in fact) only provide three of the four standard int type
sizes, with two of the four being the same size. [...]

In a 64-bit program for SPARC there are four different
integer widths: 8-bit char, 16-bit short, 32-bit int, and
64-bit long and long long.

Again, that's only three int sizes (four if you count 'char' as an int
type, which I'm not).

A 64-bit CPU could come the closest to having all four int
sizes: 16/32/64/128. But I don't know of any 64-bit C compilers
that do.

My (possibly faulty) recollection has it that the DEC
Alpha used the same arrangement (without "long long") in
its compilers for OSF/1.

Yes, the DEC Alpha 64-bit CPU for OSF/1 used 16/32/64 ints
with 64-bit pointers (it did not have 'long long'). If it had had
128-bit 'long long', it would have been the first in my experience
with four different int sizes, but it didn't.

-drt

 

[Eric Sosman]

David R Tribble wrote On 03/27/06 12:35,:

It's interesting to note that most implementations (all of them I've
ever seen, in fact) only provide three of the four standard int type
sizes, with two of the four being the same size. [...]

In a 64-bit program for SPARC there are four different
integer widths: 8-bit char, 16-bit short, 32-bit int, and
64-bit long and long long.

Again, that's only three int sizes (four if you count 'char' as an int
type, which I'm not).

I was misled by the table in your post, whose
column headers listed five integer types (plus "word").

(Also: Why in the world do you exclude `char' from
the repertoire of "standard int types?" Are you put off
by the uncertainty over its signedness, perhaps? When I
spotted the mismatch between your "four standard int types"
and the six columns in the table, I quickly excluded "word"
but then guessed you'd forgotten to count `long long'. It
never occurred to me that you'd, er, recharacterize `char'
as a non-integer -- and it seems a bizarre stance for a C
programmer to take.)

 

[Jordan Abel]

David R Tribble wrote On 03/27/06 11:44,:

It's interesting to note that most implementations (all of them I've
ever seen, in fact) only provide three of the four standard int type
sizes, with two of the four being the same size. [...]

In a 64-bit program for SPARC there are four different
integer widths: 8-bit char, 16-bit short, 32-bit int, and
64-bit long and long long.

I don't think he was counting char, when he talked about "three" of
"four".

 

[Keith Thompson]

It's interesting to note that most implementations (all of them I've
ever seen, in fact) only provide three of the four standard int type
sizes, with two of the four being the same size. [...]

In a 64-bit program for SPARC there are four different
integer widths: 8-bit char, 16-bit short, 32-bit int, and
64-bit long and long long.

Again, that's only three int sizes (four if you count 'char' as an int
type, which I'm not).

Well, you should, because it is.

8/16/32/64 is fairly common these days. Making full use of all 5
integer type sizes, assuming 8-bit char, would of course require
8/16/32/64/128 -- and I've never seen a system with 128-bit integers.

When 32-bit integers and pointers were common, it wasn't difficult to
foresee that they would become inadequate, and that we'd move to 64
bits. Now that 64-bit integers and pointers are becoming widespread,
I suspect we've reached a plateau; I don't think we'll move on to 128
bits for several decades. A 16-exabyte address space will keep me
happy for quite a while; even where I work, we're barely dealing with
petabytes, and that's not directly addressible.

 

[Jordan Abel]

When I spotted the mismatch between your "four standard int types" and
the six columns in the table, I quickly excluded "word" but then
guessed you'd forgotten to count `long long'. It never occurred to me
that you'd, er, recharacterize `char' as a non-integer -- and it seems
a bizarre stance for a C programmer to take.)

The keyword "int" is not allowed as part of its type name, therefore it
is arguable that it is not an "int type" despite being an "integer
type".

 

[Jordan Abel]

It's interesting to note that most implementations (all of them I've
ever seen, in fact) only provide three of the four standard int type
sizes, with two of the four being the same size. [...]

In a 64-bit program for SPARC there are four different
integer widths: 8-bit char, 16-bit short, 32-bit int, and
64-bit long and long long.

Again, that's only three int sizes (four if you count 'char' as an int
type, which I'm not).

Well, you should, because it is.

8/16/32/64 is fairly common these days. Making full use of all 5
integer type sizes, assuming 8-bit char, would of course require
8/16/32/64/128 -- and I've never seen a system with 128-bit integers.

When 32-bit integers and pointers were common, it wasn't difficult to
foresee that they would become inadequate, and that we'd move to 64
bits. Now that 64-bit integers and pointers are becoming widespread,
I suspect we've reached a plateau; I don't think we'll move on to 128
bits for several decades. A 16-exabyte address space will keep me
happy for quite a while; even where I work, we're barely dealing with
petabytes, and that's not directly addressible.

a 128-bit word size might make sense, though, for a specialized system
that is intended to mainly work with high-precision floating point,
though. But I'll agree that probably LP64/LLP64 are going to be the most
common model for hosted systems from here on out. [those are 8/16/32/64
with 64- and 32-bit long, respectively, and 64-bit pointers.]

 

[Keith Thompson]

The keyword "int" is not allowed as part of its type name, therefore it
is arguable that it is not an "int type" despite being an "integer
type".

The language makes no such distinction. Type char is an integer type;
the only thing that's really special about it is that plain char may
be either signed or unsigned.