Need to Allocate more space than size_t

[ramasubramanian.rahul]

hi folks
i have a peculiar problem. i have to allocate more than size_t
consequtive bytes on a system . after i do a malloc .. i am unable to
do a realloc because it takes size_t as a new size and not as an
incremental size..
can you tell me which library/system call to use..
Plz consider that all the physical hardware req for such an operation
is available... i know this sounds crazy... but just help me out here
....
Thanks in Advance
Rahul

[Tor Rustad]

ra************* ******@gmail.co m wrote:

hi folks
i have a peculiar problem. i have to allocate more than size_t
consequtive bytes on a system . after i do a malloc .. i am unable to
do a realloc because it takes size_t as a new size and not as an
incremental size..
can you tell me which library/system call to use..
Plz consider that all the physical hardware req for such an operation
is available... i know this sounds crazy... but just help me out here

I suggest getting a C compiler that support your hardware. So, if you
have a 64-bit system, then you need a compiler which support for e.g.
LP64 model. You cannot expect a ILP32 compiler to give you some magic
way to address an object with greater size than 32-bit.

--
Tor <torust AT online DOT no>

[Frederick Gotham]

ra************* ******@gmail.co m:

hi folks
i have a peculiar problem. i have to allocate more than size_t
consequtive bytes on a system . after i do a malloc .. i am unable to
do a realloc because it takes size_t as a new size and not as an
incremental size..
can you tell me which library/system call to use..
Plz consider that all the physical hardware req for such an operation
is available... i know this sounds crazy... but just help me out here
...

Either:

(1) Your particular implementation intends such large chunks of memory to
be allocated via implementation-specific means (e.g. System API function).
(2) Your particular implementation intends for you to be able to allocate
such large chunks of memory using Standard C, but has neglected to make
"size_t" big enough.

Solutions:

(1) Unfortunately, you'll have to resort to implementation-specific means.
(2) You'll have to contact your compiler manufacturer and ask for a fix, or
perhaps try fix it yourself (e.g. altering the size_t typedef)
That's as much as I can tell you without going Off-Topic here.

--

Frederick Gotham

[Tor Rustad]

Frederick Gotham wrote:

Solutions:

(1) Unfortunately, you'll have to resort to implementation-specific means.

The problem is that OP's implementation doesn't support his HW
archtecture.

(2) You'll have to contact your compiler manufacturer and ask for a fix, or
perhaps try fix it yourself (e.g. altering the size_t typedef)

How is changing size_t typedef gonna help?

--
Tor <torust AT online DOT no>

[Frederick Gotham]

Tor Rustad:

Frederick Gotham wrote:

>Solutions:

(1) Unfortunately, you'll have to resort to implementation-specific
means.

The problem is that OP's implementation doesn't support his HW
archtecture.

If you're supposed to be able to allocate a terrabyte of memory without
resorting to implementation-specific means, then "size_t" should be able to
hold a large enough value.

If this is indeed intended, then the implementation is flawed in that
size_t isn't big enough.

If this isn't intended, then you'll have to use implementation-specific
means to achieve your goal.

>(2) You'll have to contact your compiler manufacturer and ask for a
fix, or perhaps try fix it yourself (e.g. altering the size_t typedef)

How is changing size_t typedef gonna help?

Perhaps it's defined(Do you "declare" or do you "define" a typedef?) as
follows in his/her system headers:

typedef long unsigned size_t;

, and perhaps he/she can change it to something platform-specific like:

typedef __int128 unsigned size_t;

Of course, this might mess up his/her entire system.

--

Frederick Gotham

[Random832]

2006-11-14 <wO************ *******@news.in digo.ie>,
Frederick Gotham wrote:

Perhaps it's defined(Do you "declare" or do you "define" a typedef?) as
follows in his/her system headers:

typedef long unsigned size_t;

, and perhaps he/she can change it to something platform-specific like:

typedef __int128 unsigned size_t;

Of course, this might mess up his/her entire system.

You misspelled "will".

He'd have to, at the _very_ least, modify and recompile all his libraries.

[Old Wolf]

ra************* ******@gmail.co m wrote:

hi folks
i have a peculiar problem. i have to allocate more than size_t
consequtive bytes on a system . after i do a malloc .. i am unable to
do a realloc because it takes size_t as a new size and not as an
incremental size..
can you tell me which library/system call to use..

You could use calloc( ), it can allocate more memory than
SIZE_MAX. Then copy all the data from your previous allocation,
and free it.

[Ian Collins]

Old Wolf wrote:

ra************* ******@gmail.co m wrote:

>>hi folks
i have a peculiar problem. i have to allocate more than size_t
consequtive bytes on a system . after i do a malloc .. i am unable to
do a realloc because it takes size_t as a new size and not as an
incremental size..
can you tell me which library/system call to use..

You could use calloc( ), it can allocate more memory than
SIZE_MAX. Then copy all the data from your previous allocation,
and free it.

Doing the copy could be a bit of a challenge if you have more memory
than the size of a pointer.

--
Ian Collins.

[Keith Thompson]

Frederick Gotham <fg*******@SPAM .comwrites:
[...]

Either:

(1) Your particular implementation intends such large chunks of memory to
be allocated via implementation-specific means (e.g. System API function).
(2) Your particular implementation intends for you to be able to allocate
such large chunks of memory using Standard C, but has neglected to make
"size_t" big enough.

Solutions:

(1) Unfortunately, you'll have to resort to implementation-specific means.
(2) You'll have to contact your compiler manufacturer and ask for a fix, or
perhaps try fix it yourself (e.g. altering the size_t typedef)
That's as much as I can tell you without going Off-Topic here.

No, altering the size_t typedef in your implementation' s <stddef.h>
file (assuming it's a file) will not help. It's not absolutely
guaranteed to break the implementation (it's barely conceivable that
everything would magically work correctly with the modified typedef),
but I'd be astonished if it actually worked.

Don't try modify your implementation' s system header files unless
you're absolutely sure you know what you're doing. And if you *think*
you're absolutely sure you know what you're doing, you're probably
mistaken.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <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]

"Old Wolf" <ol*****@inspir e.net.nzwrites:

ra************* ******@gmail.co m wrote:

>hi folks
i have a peculiar problem. i have to allocate more than size_t
consequtive bytes on a system . after i do a malloc .. i am unable to
do a realloc because it takes size_t as a new size and not as an
incremental size..
can you tell me which library/system call to use..

You could use calloc( ), it can allocate more memory than
SIZE_MAX. Then copy all the data from your previous allocation,
and free it.

Not necessarily. calloc() takes two arguments, and the number of
bytes allocated is their product, but it's likely that an attempt to
allocate more than SIZE_MAX bytes will fail. Also, calloc()
zero-initializes the allocated space; with the amount of memory we're
talking about, that could take a significant amount of time.

If you really need to deal with more than SIZE_MAX bytes, your best
bet is probably to use a file (or to use a system with a larger
SIZE_MAX).

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <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.

[Randy Howard]

ra************* ******@gmail.co m wrote
(in article
<11************ *********@m73g2 000cwd.googlegr oups.com>):

hi folks
i have a peculiar problem. i have to allocate more than size_t
consequtive bytes on a system .

Then you are using a compiler not properly matched to the
system, otherwise size_t would be plenty big.

can you tell me which library/system call to use..

The existing ones work fine, provided your implementation is
suited to the host architecture.

Plz consider that all the physical hardware req for such an operation
is available... i know this sounds crazy... but just help me out here

Using a 32-bit compiler on a 64-bit system by chance?

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw