«

Suppose an implementation where
sizeof int == 4
sizeof void * == 8
sizeof long long == 8

When indexing an array

array[integer expression]

this would mean that arrays are limited to 2GB. To overcome this,
is an implementation allowed to cast array indexes to long long?

Thanks in advance for your attention.

References:
6.5.2.1 Array subscripting
Constraints
1 One of the expressions shall have type ‘‘pointer to object type’’, the
other expression shall have integer type, and the result has type
‘‘type’’.

jacob

In article <455d7f20$0$25910$>,
jacob navia <> wrote:
>Suppose an implementation where
>sizeof int == 4
>sizeof void * == 8
>sizeof long long == 8

>When indexing an array

>array[integer expression]

>this would mean that arrays are limited to 2GB.

No it wouldn't.

>To overcome this,
>is an implementation allowed to cast array indexes to long long?

No need for the implementation to cast them.


>References:
>6.5.2.1 Array subscripting
>Constraints
>1 One of the expressions shall have type ‘‘pointer to object type’’, the
>other expression shall have integer type, and the result has type
>‘‘type’’.

Notice that's "the other expression shall have integer type", not
"the other expression shall have int type". Any integer type is allowed.
The expression is equivilent to pointer arithmetic followed by a
dereference, and any integral type can be added to a pointer,
as long as the result points within the same object.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

Walter Roberson a écrit :
> In article <455d7f20$0$25910$>,
> jacob navia <> wrote:
>
>>Suppose an implementation where
>>sizeof int == 4
>>sizeof void * == 8
>>sizeof long long == 8
>
>
>>When indexing an array
>
>
>>array[integer expression]
>
>
>>this would mean that arrays are limited to 2GB.
>
>
> No it wouldn't.
>
>
>>To overcome this,
>>is an implementation allowed to cast array indexes to long long?
>
>
> No need for the implementation to cast them.
>
>
>
>>References:
>>6.5.2.1 Array subscripting
>>Constraints
>>1 One of the expressions shall have type ‘‘pointer to object type’’, the
>>other expression shall have integer type, and the result has type
>>‘‘type’’.
>
>
> Notice that's "the other expression shall have integer type", not
> "the other expression shall have int type". Any integer type is allowed.
> The expression is equivilent to pointer arithmetic followed by a
> dereference, and any integral type can be added to a pointer,
> as long as the result points within the same object.

RIGHT!!!

Damm, I just didn't see it.

Thanks a lot for your quick answer.

In article <ejjv93$35q$>,
Walter Roberson <> wrote:

Minor correction about array indexing:

>The expression is equivilent to pointer arithmetic followed by a
>dereference, and any integral type can be added to a pointer,
>as long as the result points within the same object.

The dereference would not necessarily be there; the dereference
would be inferred in contexts in which a value was required.
In particular, not in the context of & or sizeof, or of the array
indexing appearing as an lvalue.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton

>In article <455d7f20$0$25910$>,
>jacob navia <> wrote (in part):
>>array[integer expression]
...
>>To overcome this,
>>is an implementation allowed to cast array indexes to long long?

(This, of course, is why the "best" type for array indexing is
generally size_t, or a signed variant of size_t: size_t can [and
should] be "unsigned long long" on implementations with memory
sizes exceeding UINT_MAX.)

In article <ejjv93$35q$>
Walter Roberson <> wrote:
>No need for the implementation to cast them.

Moreover, if an implementation does an internal conversion of whatever
integral type is being added to a pointer value, so that:

ptr + i

and:

*(ptr + i) /* aka ptr[i] */

convert the value in "i" to (signed or unsigned) "long long" before
doing the addition, this is still an "internal conversion", *not* a
"cast". A cast is the syntactic construct in which a type-name
enclosed in parentheses is used to force an explicit conversion.

(Note that most implementations do indeed convert "i", if it is
plain, signed, or unsigned char; plain or signed short; or unsigned
short. That is:

unsigned char i;
...
use(ptr[i]);

has the same effect as a version with a cast:

use(ptr[(int)i]);

It is tempting to call internal conversions "implicit casts", but
ever since the original ANSI C standard -- which defined "cast" as
the explicit conversion, and nothing else -- came out, this temptation
should be resisted.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

jacob navia:

> Suppose an implementation where
> sizeof int == 4
> sizeof void * == 8
> sizeof long long == 8
>
> When indexing an array
>
> array[integer expression]
>
> this would mean that arrays are limited to 2GB.


No, for two reasons:

(1) CHAR_BIT is 797525.
(2) The implementation may provide an integer type bigger than "long long"
(or at least I think so).

--

Frederick Gotham

jacob navia <> wrote:
# Suppose an implementation where
# sizeof int == 4
# sizeof void * == 8
# sizeof long long == 8
#
# When indexing an array
#
# array[integer expression]
#
# this would mean that arrays are limited to 2GB. To overcome this,
# is an implementation allowed to cast array indexes to long long?

It's not worth having more than a 32 bit index if you only have
a 32 bit address. And while 64 bit addresses date back to the Star 100,
they are becoming widely available in the last few years, openning
a whole new world of debugging.

May you live in interesting times.

(Once the 64-bit barrier is crossed, then we get to deal with the
Y2K38 bug.)

--
SM Ryan http://www.rawbw.com/~wyrmwif/
There are subtler ways of badgering a witness.

"jacob navia" <> wrote in message
> Suppose an implementation where
> sizeof int == 4
> sizeof void * == 8
> sizeof long long == 8
>
> When indexing an array
>
> array[integer expression]
>
> this would mean that arrays are limited to 2GB. To overcome this,
> is an implementation allowed to cast array indexes to long long?
>
> Thanks in advance for your attention.
>
> References:
> 6.5.2.1 Array subscripting
> Constraints
> 1 One of the expressions shall have type ‘‘pointer to object type’’, the
> other expression shall have integer type, and the result has type
> ‘‘type’’.
>
An int should be a natural register type.
So you've got to ask how the implementation can address more memory than
will fit in a register, ignoring the signed /unsigned issue.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

"Malcolm" <> writes:
> "jacob navia" <> wrote in message
>> Suppose an implementation where
>> sizeof int == 4
>> sizeof void * == 8
>> sizeof long long == 8
[...]
> An int should be a natural register type.
> So you've got to ask how the implementation can address more memory than
> will fit in a register, ignoring the signed /unsigned issue.

The implementer has to think about that, but a programmer doesn't.

On many systems, int and size_t happen to be the same size, so the
question doesn't even come up. But if size_t is bigger than int, then
presumably the implementation will do whatever is necessary to make
that work. As a programmer, though I might be curious, I don't need
to know how it's done, merely that it works.

(On a number of systems I use every day, int is 32 bits, but pointers
are 64 bits.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

"Keith Thompson" <kst-> wrote in message
news:...
> "Malcolm" <> writes:
>> "jacob navia" <> wrote in message
>>> Suppose an implementation where
>>> sizeof int == 4
>>> sizeof void * == 8
>>> sizeof long long == 8
> [...]
>> An int should be a natural register type.
>> So you've got to ask how the implementation can address more memory than
>> will fit in a register, ignoring the signed /unsigned issue.
>
> The implementer has to think about that, but a programmer doesn't.
>
> On many systems, int and size_t happen to be the same size, so the
> question doesn't even come up. But if size_t is bigger than int, then
> presumably the implementation will do whatever is necessary to make
> that work. As a programmer, though I might be curious, I don't need
> to know how it's done, merely that it works.
>
I'm programming MPI. The code is mainly in C but has to call Fortran
subroutines.
So size_t's are a big no-no. I'm not convinced the MPI will serialise them
correctly and portably, and they certainly are in danger of breaking if
passed to the Fortran routines.

My own view is that portability, reusability, readability etc is improved if
we reduce the number of types. Basically the programmer wants characters and
numbers. However you need to split numbers into integers and reals as a
concession to efficiency, and also because many type are naturally integral.
The C needs pointers for its internals. So that would be four types -
characters, integers, reals and pointers. char, int, double and the * types.
Finally you also need an 8 bit "byte" as a concession to efficient layout of
patterns in memory. So, sadly, my proposal has ended up adding a keyword
after all.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.