Big arrays (confusion over FAQ 6.14)

[Andrew Fabbro]

I have a need to create an array that is larger than size_t - 1, which
I believe is the largest guaranteed array. I though I'd found
salvation in FAQ 6.14, but it appears I am not understanding
something.

The array is an array of pointers to structs. Here is an example
using a small array:

/* checks that malloc succeeded, main's return, etc. removed for
brevity */

#include <stdio.h>
#include <stdlib.h>

typedef struct {
int foo;
int bar;
} example_struct;

int main (void) {
example_struct * small_array[1000];
example_struct * a_single_struct;

a_single_struct = malloc ( sizeof(example_struct *) );
a_single_struct->foo = 4000;
printf ("a_single_struct foo: %i \n", a_single_struct->foo);

small_array[900] = a_single_struct;
printf ("small_array 900 foo: %i\n",small_array[900]->foo);

}

This works fine:

a_single_struct foo: 4000
small_array 900 foo: 4000

So far, so good. Now I want to do an array of, say, 3,000,000
members, too large for a simple big_array[3000000] declaration. So I
use the code from faq 6.14:

/* checks that malloc succeeded, main's return, etc. removed for
brevity */

#include <stdio.h>
#include <stdlib.h>

typedef struct {
int foo;
int bar;
} example_struct;

int main (void) {
example_struct * big_array;
example_struct * a_single_struct;

a_single_struct = malloc ( sizeof(example_struct *) );
a_single_struct->foo = 4000;
printf ("a_single_struct foo: %i \n", a_single_struct->foo);

big_array = malloc ( 3000000 * sizeof ( example_struct * ) );
big_array[1000000] = a_single_struct; /* line 20, error below */
printf ("big_array foo: %i\n",big_array[1000000]->foo);

}

No go. The compiler (gcc in this case) returns:

test.c: In function 'main':
test.c:20: error: incompatible types in assignment
test.c:21: error: invalid type argument of '->'

So the example in FAQ 6.14 is:

"int *dynarray;
dynarray = malloc(10 * sizeof(int));

....you can reference dynarray (for i from 0 to 9) almost as if
dynarray were a conventional, statically-allocated array (int a[10])"

Given that, I'm confused why

small_array[900] = a_simple_struct;

works, while

big_array[1000000] = a_simple_struct;

doesn't.

Is there some obvious error in my code? Have I just embarrassed
myself by displaying my obtusity before the comp.lang.c gods? Or is
there some better method of creating arrays > (size_t - 1) ?

Thanks.

 

[CBFalconer]

I have a need to create an array that is larger than size_t - 1,
which I believe is the largest guaranteed array. I though I'd
found salvation in FAQ 6.14, but it appears I am not
understanding something.

You can't have it. No object whose size cannot be measured in a
size_t can exist. What are you trying to do?

 

[Malcolm McLean]

You can't have it. No object whose size cannot be measured in a
size_t can exist. What are you trying to do?

It can exist in the backing store.
As long as you don't need too many random accesses to your array, store it
on disk and read in chunks as you need.
Unfortunately the fseek() function quite often takes a long, which might not
be big enough. The fsetpos() takes yet another data type, fpos_t, and may
not be available.

 

[Army1987]

I have a need to create an array that is larger than size_t - 1, which
I believe is the largest guaranteed array. I though I'd found
salvation in FAQ 6.14, but it appears I am not understanding
something.

On modern PCs, (size_t)(-1) is one byte less than 4 GB (on 32-bit
processors), or about 2.8 GB times the human population of the
Earth (on 64-bit processors). You are very likely *not* to have
enough memory, and if you have I think is impossible (or almost so)
to access it. What the hell are you trying to do? You might store
all those structs on a disk file.
(If you're programming for MS-DOS or some other system where it is
not absurd to have more memory than (size_t)(-1), go to
comp.os.msdos.programming or whatever.)

 

[Jens Thoms Toerring]

I have a need to create an array that is larger than size_t - 1, which
I believe is the largest guaranteed array. I though I'd found
salvation in FAQ 6.14, but it appears I am not understanding
something.

The array is an array of pointers to structs. Here is an example
using a small array:

/* checks that malloc succeeded, main's return, etc. removed for
brevity */

#include <stdio.h>
#include <stdlib.h>

typedef struct {
int foo;
int bar;
} example_struct;

int main (void) {
example_struct * small_array[1000];
example_struct * a_single_struct;

a_single_struct = malloc ( sizeof(example_struct *) );

You already have a severe problem here: you don't allocate
enough memory. What you need to to allocate is not just a
pointer to an 'example_struct' (that you already have with
'a_single_struct'), but enough memory for an 'example_struct'.
So you need here

a_single_struct = malloc) sizeof( example_struct ) );

a_single_struct->foo = 4000;

With your alloction this only works by pure luck - if the
size of an 'example_struct' is larger than that of a pointer
to such a structure then you may be overwriting memory you
didn't allocate (since on most machines the size of a pointer
is at least as large as that of an int you may just have
avoided disaster since you only wrote to the 'foo' member,
but if you also write to the 'bar' member then things will
look worse....)

printf ("a_single_struct foo: %i \n", a_single_struct->foo);

small_array[900] = a_single_struct;
printf ("small_array 900 foo: %i\n",small_array[900]->foo);

}

This works fine:

a_single_struct foo: 4000
small_array 900 foo: 4000

Unfortunately, it only looks like it works fine.

So far, so good. Now I want to do an array of, say, 3,000,000
members, too large for a simple big_array[3000000] declaration. So I
use the code from faq 6.14:

/* checks that malloc succeeded, main's return, etc. removed for
brevity */

#include <stdio.h>
#include <stdlib.h>

typedef struct {
int foo;
int bar;
} example_struct;

int main (void) {
example_struct * big_array;
example_struct * a_single_struct;

a_single_struct = malloc ( sizeof(example_struct *) );
a_single_struct->foo = 4000;
printf ("a_single_struct foo: %i \n", a_single_struct->foo);

You have the same problem here as above...

big_array = malloc ( 3000000 * sizeof ( example_struct * ) );

'big_array' is a pointer to an 'example_struct', but you
allocate memory for 3000000 pointers to 'example_struct'
which you then assign to 'big_array'.

big_array[1000000] = a_single_struct; /* line 20, error below */

And here you get caught: since 'big_array' is of type
pointer to 'example_struct' big_array[1000000] is of
type 'example_struct', but what you try to assign it
is of type pointer to 'example_struct' and that's why
the compiler tells you

test.c:20: error: incompatible types in assignment

Since you want an array of pointers to 'example_struct'
you must define 'big_array' to be a pointer to pointer
to 'example_struct', i.e.

example_struct ** big_array;

to get things to work.

printf ("big_array foo: %i\n",big_array[1000000]->foo);

And since 'big_array[1000000]' is of type 'example_struct'
(and not pointer to such a structure) you can't use '->'
with that as the compiler tells you with

test.c:21: error: invalid type argument of '->'

Or is
there some better method of creating arrays > (size_t - 1) ?

I don't think you really have a problem with 'size_t' here
and, BTW, size_t is a type and not a value, the maximum
value that can be stored in a variable of type size_t is
SIZE_MAX as defined in <stdint.h>, at least if your com-
piler supports this C99-ism (gcc does), which typically
is much larger than just 3 millions. I guess the problem
is rather that you want an array that's larger than the
amount of memory that the system allows you for local
"real" (fixed sized) array. But no, there's no better way
for creating large arrays (or arrays that have a variable
size) than using memory allocation at run-time.

Regards, Jens

 

[Flash Gordon]

Malcolm McLean wrote, On 12/08/07 08:25:

It can exist in the backing store.

I C terms that is not an object.

As long as you don't need too many random accesses to your array, store
it on disk and read in chunks as you need.
Unfortunately the fseek() function quite often takes a long,

Actually, it *always* takes a long on a conforming implementation.

which might
not be big enough.
True.

> The fsetpos() takes yet another data type, fpos_t,

No, it takes a pointer to fpos_t.

and may not be available.

It is not optional on hosted implementations so it will be available on
any hosted implementation claiming conformance to any version of the C
standard. It does, however, have the problem that the only value you can
portably pass to it is one obtained with fgetpos.

You also have the problem that the file system might not support a
sufficiently large file.

 

[Mark McIntyre]

On modern PCs, (size_t)(-1) is one byte less than 4 GB (on 32-bit
processors), or about 2.8 GB times the human population of the
Earth (on 64-bit processors). You are very likely *not* to have
enough memory,

These days, blade PCs with 8+GB aren't that rare, especially in the
commercial sector.

and if you have I think is impossible (or almost so)
to access it.

4 arrays of 2 GB ?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Eric Sosman]

I have a need to create an array that is larger than size_t - 1, which
I believe is the largest guaranteed array.

If you mean `(size_t)-1', you're out of luck: No object can
have more than SIZE_MAX bytes. Also, it's likely that the O/S
and the rest of your program will chew up some amount of memory,
so you won't even be able to get that high. It's a "theoretical"
upper limit, not a practical one.

Note that if an array's elements are bigger than one byte
each, then the theoretical upper limit on element count will be
even lower. For example, an array of eight-byte elements cannot
possibly have more than `SIZE_MAX / 8' array slots to stay
within the allowable limit on overall byte count.

I though I'd found
salvation in FAQ 6.14, but it appears I am not understanding
something.

The array is an array of pointers to structs. Here is an example
using a small array:

/* checks that malloc succeeded, main's return, etc. removed for
brevity */

#include <stdio.h>
#include <stdlib.h>

typedef struct {
int foo;
int bar;
} example_struct;

int main (void) {
example_struct * small_array[1000];
example_struct * a_single_struct;

a_single_struct = malloc ( sizeof(example_struct *) );

This line requests enough memory for one struct pointer,
not for one struct. In this sample program you only make
use of the first int in the struct, and that's probably why
you seem to get away with the error. But if you tried to
use the second int you'd be very likely to get into trouble.

Avoiding this and similar errors is the big advantage of
the c.l.c. Approved Allocation Idiom:

a_single_struct = malloc(sizeof *a_single_struct);

.... or more generally

pointer = malloc(count * sizeof *pointer);

One thing to be wary of when allocating "huge" arrays, even
with this improved form, is that the multiplication may not give
the right answer. If the mathematical product of the two terms
is larger than SIZE_MAX, the result is reduced modulo that
amount plus one and you'll wind up requesting a much smaller
block of memory. Your struct is probably about eight bytes
long; if `count' were `SIZE_MAX / 3', say, the mathematical
product would be about two and two-thirds times SIZE_MAX, and
the eventual result would be about two-thirds SIZE_MAX, or
roughly one-quarter the size you intended.

(Pedantry alert: The above description does not hold on
"exotic" machines where SIZE_MAX < INT_MAX. I've never heard
of such a machine, but the C Standard doesn't forbid them.)

a_single_struct->foo = 4000;
printf ("a_single_struct foo: %i \n", a_single_struct->foo);

small_array[900] = a_single_struct;
printf ("small_array 900 foo: %i\n",small_array[900]->foo);

}

This works fine:

a_single_struct foo: 4000
small_array 900 foo: 4000

So far, so good. Now I want to do an array of, say, 3,000,000
members, too large for a simple big_array[3000000] declaration. So I
use the code from faq 6.14:

/* checks that malloc succeeded, main's return, etc. removed for
brevity */

#include <stdio.h>
#include <stdlib.h>

typedef struct {
int foo;
int bar;
} example_struct;

int main (void) {
example_struct * big_array;
example_struct * a_single_struct;

a_single_struct = malloc ( sizeof(example_struct *) );

Same error as above.

a_single_struct->foo = 4000;
printf ("a_single_struct foo: %i \n", a_single_struct->foo);

big_array = malloc ( 3000000 * sizeof ( example_struct * ) );

This might be the same error as above, but if I understand
your purpose I think the actual error is that big_array is not
declared correctly. You may want

example_struct **big_array;

(The c.l.c. AAI works correctly with this declaration, too.)

big_array[1000000] = a_single_struct; /* line 20, error below */
printf ("big_array foo: %i\n",big_array[1000000]->foo);

These would be correct with the revised big_array declaration.
As things stand, big_array[1000000] is not a struct pointer, but
a struct instance. If that's what you want, you could use

big_array[1000000] = *a_single_struct;
printf (... big_array[1000000].foo);

}

No go. The compiler (gcc in this case) returns:

test.c: In function 'main':
test.c:20: error: incompatible types in assignment
test.c:21: error: invalid type argument of '->'

So the example in FAQ 6.14 is:

"int *dynarray;
dynarray = malloc(10 * sizeof(int));

...you can reference dynarray (for i from 0 to 9) almost as if
dynarray were a conventional, statically-allocated array (int a[10])"

Given that, I'm confused why

small_array[900] = a_simple_struct;

works, while

big_array[1000000] = a_simple_struct;

doesn't.

Is there some obvious error in my code? Have I just embarrassed
myself by displaying my obtusity before the comp.lang.c gods? Or is
there some better method of creating arrays > (size_t - 1) ?

Thanks.

 

[Army1987]

These days, blade PCs with 8+GB aren't that rare, especially in the
commercial sector.

What kind of processor do they have? How wide is their size_t?
I still think that having more than 4GB on a computer with a 32
bit processor is *very* silly.

 

[Mark McIntyre]

What kind of processor do they have?

Itanium and Amd-64, typically.

I still think that having more than 4GB on a computer with a 32
bit processor is *very* silly.

Its just trickier to use.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

Itanium and Amd-64, typically.

Right, and such systems almost certainly have a 64-bit size_t, which
makes them irrelevant to the current discussion unless they have more
than 16 exabytes of memory.

(On the other hand, both Itanium and x86-64 systems are capable of
running x86-32 executables.)

Its just trickier to use.

True. Leaving aside any specific architectures, the range of size_t
limits the size of a single object, not the size of memory. A system
with a 32-bit size_t can't have an object bigger than 4 gigabytes
(ignoring the old debate about calloc()), but there's no reason as far
as standard C is concerned why many such objects couldn't exist within
a single program, or within multiple programs.

If the objects in a single program can exceed 4 gigabytes, then void*
has to be bigger than 32 bits, since each byte of each object must
have a unique address. If no one object can exceed 4 gigabytes, then
size_t can be just 32 bits. (Note that I'm using the term "gigabyte"
here to refer to 2**32 bytes, not necessarily 2**32 octets.)

We've gotten so used to flat address spaces that we sometimes tend to
conflate these things.

 

[Andrew Fabbro]

You can't have it. No object whose size cannot be measured in a

size_t can exist. What are you trying to do?

Thank you all for your learned responses. But now it appears I'm
slightly more confused.

Without getting too platform-specific, on this platform, size_t is 32-
bit...so a declaration of some_array[3000000] should work, right? The
limit would be 4,294,967,295 (2^32-1), right?

My intention was to:

1. declare a 3000000-member array of struct pointers. This is because
I'm looking up individual structs by index number ("give me the info
for # 17272") and an array makes it simple. The real code has a small
linked list for each member and accessing data in this way has been
very fast.
2. malloc space for each pointer (I see what you all are saying - my
example was sloppy)
3. initialize each member
4. process data, etc.

However, this code fails, and I'm confused as to why:

#include <stdio.h>
#include <stdlib.h>

typedef struct {
int foo;
int bar;

} example_struct;

int main (void) {
example_struct big_array[3000000];
int i;

for (i = 0; i <= 2999999; i++ ) {
big_array.foo = i;
}

printf ("number 200 is %i\n",big_array[200].foo);
}

I get a segmentation fault (it's gcc under 32-bit linux, though that
shouldn't matter). BUT...if I change it to big_array[300] and change
the for loop limit to <=299, it works fine. So does that mean I'm
hitting some sort of limit?

It's not a memory limit, I don't think...the struct is 8 bytes. 3
million * 8 bytes = 24 million bytes. The box has 2GB of RAM. I
wrote code that mallocs 50,000,000 bytes as a test and the malloc call
succeeded (indeed, I have code that works with over 1GB of malloc'd
RAM with no problem).

So is there a limit to how many members you can have in an array? If
so, how do I determine what that limit is? Googling c.l.c says it's
size_t - 1, but....???

 

[Justin Spahr-Summers]

I get a segmentation fault (it's gcc under 32-bit linux, though that
shouldn't matter). BUT...if I change it to big_array[300] and change
the for loop limit to <=299, it works fine. So does that mean I'm
hitting some sort of limit?

It's not a memory limit, I don't think...the struct is 8 bytes. 3
million * 8 bytes = 24 million bytes. The box has 2GB of RAM. I
wrote code that mallocs 50,000,000 bytes as a test and the malloc call
succeeded (indeed, I have code that works with over 1GB of malloc'd
RAM with no problem).

The limit lies not with the heap, but the stack space of your program.
The stack is generally used for small data sets (such as variables
with automatic storage duration and small to medium-sized arrays) and
often has a limit on the size it can grow to. Is there some reason you
don't wish to malloc() 3,000,000 example_struct objects instead?

 

[Ben Pfaff]

int main (void) {
example_struct big_array[3000000];
[...]

}

You may be encountering a limitation on the size of an automatic
array, rather than a limitation on the size of an object.
Allocate the array statically or dynamically instead <OT>or try
"ulimit -s unlimited"</OT>.

 

[Flash Gordon]

Andrew Fabbro wrote, On 12/08/07 22:52:

You can't have it. No object whose size cannot be measured in a
size_t can exist. What are you trying to do?

Thank you all for your learned responses. But now it appears I'm
slightly more confused.

Without getting too platform-specific, on this platform, size_t is 32-
bit...so a declaration of some_array[3000000] should work, right? The
limit would be 4,294,967,295 (2^32-1), right?

<snip>

Yes and no. That is one possible upper limit, but the implementation is
allowed to have a much smaller limit than that.

So is there a limit to how many members you can have in an array? If
so, how do I determine what that limit is? Googling c.l.c says it's
size_t - 1, but....???

I think you meant (size_t)-1, i.e. -1 cast to size_t. However, you are
correct that there is probably a lower limit than that being applied
(the language definition allows this) and the only way to find out what
it is is to read the documentation for your specific implementation.
You've mentioned gcc, so you need to read the gcc documentation, but you
also may need to read the documentation for the linker (typically ld on
*nix) and also the OS, because any of these may impact on the limit.
Specifically, I know that under Linux you can set various limits on
processes, and if you are not the system administrator then it could be
that whoever has that role has enforced a limit on you.

If you need help in negotiating the Linux & gcc documentation to find
out what the limits are on your specific implementation, and what you
can do to change them, you will need to ask on a Linux and/or gcc group.

 

[Jens Thoms Toerring]

Thank you all for your learned responses. But now it appears I'm
slightly more confused.

Without getting too platform-specific, on this platform, size_t is 32-
bit...so a declaration of some_array[3000000] should work, right? The
limit would be 4,294,967,295 (2^32-1), right?

No, that's rather unlikely. The maximum number you can store
in a variable if type size_t is typically not the maximum size
of an array you can create. Normally the amount of memory avai-
lable for auntomatic variables is much lower (and depends on the
compiler and platform). I don't remember the exact numbers but
if I am not completely off the mark the C89 standard doesn't re-
quire from the implementation that you can obtain more 2^14 bytes
(and the C99 standard more than 2^16 bytes) for all automatic
variables existing at once.

My intention was to:

1. declare a 3000000-member array of struct pointers. This is because
I'm looking up individual structs by index number ("give me the info
for # 17272") and an array makes it simple. The real code has a small
linked list for each member and accessing data in this way has been
very fast.
2. malloc space for each pointer (I see what you all are saying - my
example was sloppy)
3. initialize each member
4. process data, etc.

However, this code fails, and I'm confused as to why:

#include <stdio.h>
#include <stdlib.h>

typedef struct {
int foo;
int bar;

} example_struct;

int main (void) {
example_struct big_array[3000000];

It's rather likely this line that gets you into the mess since
you're probably not able to get that much memory for an automatic
variable (while it's not mandated by the C standard on many imple-
mentations automatic variables get created on the stack and the
size of the stack is usually much too small for that). Thus if
you need more than a few kB of memory you better use memory you
get from malloc().

int i;

for (i = 0; i <= 2999999; i++ ) {
big_array.foo = i;
}

printf ("number 200 is %i\n",big_array[200].foo);
}

I get a segmentation fault (it's gcc under 32-bit linux, though that
shouldn't matter). BUT...if I change it to big_array[300] and change
the for loop limit to <=299, it works fine. So does that mean I'm
hitting some sort of limit?

It's not a memory limit, I don't think...the struct is 8 bytes. 3
million * 8 bytes = 24 million bytes. The box has 2GB of RAM. I
wrote code that mallocs 50,000,000 bytes as a test and the malloc call
succeeded (indeed, I have code that works with over 1GB of malloc'd
RAM with no problem).

So is there a limit to how many members you can have in an array? If
so, how do I determine what that limit is? Googling c.l.c says it's
size_t - 1, but....???

It's not the number of elements of an automatic array that is
limited, it is the total amount of memory for all automatic
variables currently existing that is limited. And the limit is
typically quite a bit lower than what you are asking for. The
maximum value of a variable of type size_t is just a theoretical
upper limit for the maximum number of elements an array can have.
But on most systems you will hardly have enough memory to create
even a char array with memory obtained via malloc() that's that
large. But if you obtain the memory via malloc() you at least
have a chance to check if you could create the array since you
can test malloc()s return value - with too large automatic arrays
you often end up with a segmentation fault.

Regards, Jens

 

[Mark McIntyre]

Right, and such systems almost certainly have a 64-bit size_t, which
makes them irrelevant to the current discussion

I disagree, since the point I was responding to was where someone said
that putting more than 4GB in a PC was pointless.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Chris Torek]

Without getting too platform-specific, on this platform, size_t is 32-
bit...so a declaration of some_array[3000000] should work, right? The
limit would be 4,294,967,295 (2^32-1), right?

If SIZE_MAX (or (size_t)-1) is 4294967295, then, yes, there is an
absolute upper limit of that many bytes ("char"s) for each object.

That does not mean you can have an object that big, though.

Consider, as an analogy, the total number of cubic feet of cabin
space in your car. If your car's interior were all squared-off
(to make calculation easy) and were exactly 4 ft high by 6 ft long
by 5 ft wide, this would be 120 cubic feet of space. We could
then be sure that a 200-cubic-foot object would *not* fit.

This does not mean that any given 100-cubic-foot object *will* fit.
If that object happens to one foot high, one foot wide, and 100
feet long, it is not going to fit.

Even if all your objects "pack nicely", if the cabin of the car
already contains something else -- such as yourself, driving --
this reduces the amount of cargo space.

(The way C objects work in the abstract, you can have "multiple
separate cars" each with however many cubic feet of cargo space,
too -- separate address spaces for separate objects -- but most
*implementations* just have one big space, or sometimes two or
three pre-carved spaces they may call "stack", "heap", and so
on.)

Ultimately, the actual limit on each object's size is "SIZE_MAX,
or whatever fits, whichever is *smaller*". (To call itself a C
implementation -- at least a "hosted" one -- the Standards-writers
say that this limit must be at least 32767 bytes in C89, or 65535
bytes in C99. Even this minimal requirement is a bit weasel-worded,
though, allowing implementors to give you less in practice.)

 

[Joe Wright]

Right, and such systems almost certainly have a 64-bit size_t, which
makes them irrelevant to the current discussion unless they have more
than 16 exabytes of memory.

(On the other hand, both Itanium and x86-64 systems are capable of
running x86-32 executables.)


True. Leaving aside any specific architectures, the range of size_t
limits the size of a single object, not the size of memory. A system
with a 32-bit size_t can't have an object bigger than 4 gigabytes
(ignoring the old debate about calloc()), but there's no reason as far
as standard C is concerned why many such objects couldn't exist within
a single program, or within multiple programs.

If the objects in a single program can exceed 4 gigabytes, then void*
has to be bigger than 32 bits, since each byte of each object must
have a unique address. If no one object can exceed 4 gigabytes, then
size_t can be just 32 bits. (Note that I'm using the term "gigabyte"
here to refer to 2**32 bytes, not necessarily 2**32 octets.)

Well, gigabyte would be 2**30 of course.

 

[Keith Thompson]

I disagree, since the point I was responding to was where someone said
that putting more than 4GB in a PC was pointless.

The actual statement, from Army1987, was:
| What kind of processor do they have? How wide is their size_t?
| I still think that having more than 4GB on a computer with a 32
| bit processor is *very* silly.

Looking upthread, I don't see any statement that putting more than 4BG
on a PC is pointless.