the maximum memory size allowed in malloc

[Jerry]

I am wondering what is the maximum size of memory that malloc() could
handle. Is there any limitation on that? Where am I supposed to get
this kind of information? Thank you everybody.

 

[Hariprasad Govardhanam]

Hello,
It depends on the platform that the program is working on like
windows, linux or mac. I THINK that the amount of memory is not limited
by anything, but physical memory. Although physical memory is extended
by Virtual memory, malloc allocates contiguous memory (meaning side by
side). So, it depends on the way platform handles the request.
Saying this, I mention that I just think that is the answer. I
hope some great programmers answer your question.

 

[those who know me have no need of my name]

in comp.lang.c i read:

I am wondering what is the maximum size of memory that malloc() could
handle. Is there any limitation on that? Where am I supposed to get
this kind of information? Thank you everybody.

malloc's argument is a size_t and the range of that type is [0,SIZE_MAX],
so the maximum you can *request* is SIZE_MAX, which value varies from
implementation to implementation and is defined in <limits.h>. whether a
request for SIZE_MAX bytes will succeed depends on factors outside of the
scope of this group.

 

[Mike Wahler]

I am wondering what is the maximum size of memory that malloc() could
handle.

The largest number (in bytes) representable by
standard type 'size_t' (declared by <stdlib.h>
and other headers). This value can and does
vary among implementations. Note that this
value isn't necessarily as large as the host
platform's available memory.

Is there any limitation on that?

See above.

Where am I supposed to get
this kind of information?

How about a C textbook? Or the ISO C standard?

-Mike

 

[Mike Wahler]

Hello,
It depends on the platform that the program is working on like
windows, linux or mac. I THINK that the amount of memory is not limited
by anything, but physical memory.

No, it's limited by the range of type 'size_t'.

Although physical memory is

Might be.

extended
by Virtual memory,

Not all platforms feature 'virtual memory'. C has
no concept of virtual memory.

malloc allocates contiguous memory (meaning side by
side).
Correct.

So, it depends on the way platform handles the request.

It depends upon the C implementation.

Saying this, I mention that I just think that is the answer.

Why not find out rather than guess?

-Mike

 

[Andrey Tarasevich]

I am wondering what is the maximum size of memory that malloc() could
handle. Is there any limitation on that? Where am I supposed to get
this kind of information? Thank you everybody.

It depends on the implementation. It is definitely not greater than
range of type 'size_t' [0, SIZE_MAX] simply because that's the type of
'malloc's parameter.

Also, in a real-life implementation it is quite possible that the actual
range of sizes 'malloc' can handle is smaller than the range if 'size_t'
type. It is possible that an implementation aliases types 'ptrdiff_t'
and 'size_t' to integral types with the same number of bits in value
representation. The former type is signed and the latter is unsigned.
This automatically means that character array size (or, more generally,
object size) in such implementation cannot be greater than SIZE_MAX/2.
This limitation can also be applied to the maximum size 'malloc' can
handle (which is a logical thing to do).

 

[Keith Thompson]

in comp.lang.c i read:

I am wondering what is the maximum size of memory that malloc() could
handle. Is there any limitation on that? Where am I supposed to get
this kind of information? Thank you everybody.

malloc's argument is a size_t and the range of that type is [0,SIZE_MAX],
so the maximum you can *request* is SIZE_MAX, which value varies from
implementation to implementation and is defined in <limits.h>. whether a
request for SIZE_MAX bytes will succeed depends on factors outside of the
scope of this group.

And a given implementation won't necessarily be able to specify the
maximum size for which malloc() will succeed. Factors that affect
whether malloc() will succeed can be related to the system as a whole
or just to the current program. malloc(1) might succeed in some
circumstances and fail in others.

 

[italy]

Sorry if my format is a bit odd. I'm using the school's library
computer.

The malloc() function expects an argument of type size_t. The maxium
size is merely the size of size_t(which is implemenation-defined, look
at limits.h). That should answer your question. Also, you shouldn't
allocate a lot of memory at once. Once the memory is freed, it will
become very fragmented, which of course isn't good.

-Adam

 

[Mike Wahler]

Sorry if my format is a bit odd. I'm using the school's library
computer.

The malloc() function expects an argument of type size_t. The maxium
size is merely the size of size_t(which is implemenation-defined, look
at limits.h). That should answer your question. Also, you shouldn't
allocate a lot of memory at once. Once the memory is freed, it will
become very fragmented, which of course isn't good.

Issues of 'fragmentation' are outside the scope of C,
but what you write above is not typical behavior of
common operating systems. It's typically the use
of many small allocations which cause fragmentation,
not a single large one. IOW I think you've got things
bass ackwards.

-Mike

 

[CBFalconer]

I am wondering what is the maximum size of memory that malloc() could
handle. Is there any limitation on that? Where am I supposed to get
this kind of information? Thank you everybody.

The C90 standard guarantees that you can get at least one object 32
kBytes in size, and this may be static, dynamic, or automatic
memory. C99 guarantees at least 64 kBytes. For any higher limit,
see your system documentation, and the results are off-topic here.

In practice most systems provide considerably more memory.

 

[Lawrence Kirby]

Hello,
It depends on the platform that the program is working on like
windows, linux or mac. I THINK that the amount of memory is not limited
by anything, but physical memory.

On systems that use virtual memory it is more likely to relate to the size
of available virtual memory. There are lots of possible limitations e.g.

The maximum value of size_t, although there have been arguments as to
whether calloc() could exceed that.

The amount of address space the implementation can make available. That
involves issues of overall address spac available (limited by things like
pointer size) and what's the largest contiguous region of memory currently
available (issues of frangmentation, system configuration limits etc.)

Although physical memory is extended
by Virtual memory,

Wrong way of thinking of it. A virtual memory system doesn't have to have
"extra" storage e.g. swap files to be useful. On a virtual memory system a
program exists completely in a virtual address space, in no sense is
vitual memory just tacking memory on the end of "physical" memory.

malloc allocates contiguous memory (meaning side by
side).

From the point of view of the program. On a virtual memory system that
would be in the virtual address space.

So, it depends on the way platform handles the request.

That's true of pretty much anything.

C itself doesn't have anything to say about virtual memory. All it cares
about is whether a program executes correctly and produces the correct
output. If an implementation that uses virtual memory can achieve that
(and they can) then there's no problem.

Lawrence

 

[Lawrence Kirby]

On Tue, 25 Jan 2005 13:22:39 -0800, Andrey Tarasevich wrote:

....

Also, in a real-life implementation it is quite possible that the actual
range of sizes 'malloc' can handle is smaller than the range if 'size_t'
type. It is possible that an implementation aliases types 'ptrdiff_t'
and 'size_t' to integral types with the same number of bits in value
representation.

Yes, that is typical although not required.

The former type is signed and the latter is unsigned.
This automatically means that character array size (or, more generally,
object size) in such implementation cannot be greater than SIZE_MAX/2.

No, there is no requirement that ptrdiff_t be able to represent all
possible object sizes, it is simply the type of the result you get when
you take the difference of 2 pointers. The implication of this, which
is one with real-world consequences, is that taking the difference of two
pointers to elements of the same array isn't always valid; it can
result in undefined behaviour.

Lawrence

 

[pete]

On systems that use virtual memory it is more likely to relate to the size
of available virtual memory.
There are lots of possible limitations e.g.

The maximum value of size_t, although there have been arguments as to
whether calloc() could exceed that.

The amount of address space the implementation can make available.

It's allowable that there may be more than ((size_t)-1) bytes
of memory available and that more than ((size_t)-1) calls to malloc
could return pointers to memory before freeing any memory.

 

[Lawrence Kirby]

It's allowable that there may be more than ((size_t)-1) bytes
of memory available and that more than ((size_t)-1) calls to malloc
could return pointers to memory before freeing any memory.

I was thinking of the memory available for a single allocation, but you
are correct that much more memory can be available to multiple
allocations. This was quite typical for 16 bit x86 implementations, at
least in certain "memory models" that they supported.

Lawrence

 

[Chris Croughton]

The C90 standard guarantees that you can get at least one object 32
kBytes in size, and this may be static, dynamic, or automatic
memory. C99 guarantees at least 64 kBytes. For any higher limit,
see your system documentation, and the results are off-topic here.

Where are those in the standard(s)? I had a long look and couldn't see
them.


Hmm, it seems that there can't be a compliant C99 implementation for
small processors any more (and that seems like a totally artificial
requirement, what in the standard requires objects of 64KB?).

In practice most systems provide considerably more memory.

But not necessarily available to a program, and not necessarily all in
one chunk.

Chris C

 

[Ben Pfaff]

Where are those in the standard(s)? I had a long look and couldn't see
them.

Here's what C99 says:

5.2.4.1 Translation limits
1 The implementation shall be able to translate and execute at least one program that
contains at least one instance of every one of the following limits:13)
....
- 65535 bytes in an object (in a hosted environment only)

Hmm, it seems that there can't be a compliant C99 implementation for
small processors any more (and that seems like a totally artificial
requirement, what in the standard requires objects of 64KB?).

The requirement applies only to hosted implementations.

 

[Andrey Tarasevich]

...

Yes, that is typical although not required.


No, there is no requirement that ptrdiff_t be able to represent all
possible object sizes, it is simply the type of the result you get when
you take the difference of 2 pointers. The implication of this, which
is one with real-world consequences, is that taking the difference of two
pointers to elements of the same array isn't always valid; it can
result in undefined behaviour.

That's the case indeed. I missed this important detail. Thanks for
pointing this out. I assumed that 'ptrdiff_t' is required to always be
able to represent the difference between two pointers pointing to
elements of the same array.

 

[CBFalconer]

Where are those in the standard(s)? I had a long look and couldn't
see them.

I don't know exactly, but they are there. Maybe if you grep for
minimum you will find it? Where is Dan Pop when needed? :-[

Hmm, it seems that there can't be a compliant C99 implementation for
small processors any more (and that seems like a totally artificial
requirement, what in the standard requires objects of 64KB?).

Twas ever so. Embedded and small systems generally know their own
requirements and limitations.

 

[S.Tobias]

Me too.

Here's what C99 says:

5.2.4.1 Translation limits
1 The implementation shall be able to translate and execute at least one program that
contains at least one instance of every one of the following limits:13)
...
- 65535 bytes in an object (in a hosted environment only)

But this doesn't say that the object must come from malloc(), which was
in the original question; it could just as well be "char ca[65535]".
Would an malloc() which always returns NULL violate the Standard?

 

[pete]

Would an malloc() which always returns NULL violate the Standard?

No.