By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,714 Members | 1,340 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,714 IT Pros & Developers. It's quick & easy.

the maximum memory size allowed in malloc

P: n/a
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.

Nov 14 '05 #1
Share this Question
Share on Google+
19 Replies


P: n/a
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.

Nov 14 '05 #2

P: n/a
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.

--
a signature
Nov 14 '05 #3

P: n/a
"Jerry" <zh********@gmail.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...
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
Nov 14 '05 #4

P: n/a

"Hariprasad Govardhanam" <ha*******************@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
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
Nov 14 '05 #5

P: n/a
Jerry wrote:
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).

--
Best regards,
Andrey Tarasevich
Nov 14 '05 #6

P: n/a
those who know me have no need of my name <no****************@usa.net> writes:
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.

--
Keith Thompson (The_Other_Keith) 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.
Nov 14 '05 #7

P: n/a
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

Nov 14 '05 #8

P: n/a
"italy" <it****@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
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
Nov 14 '05 #9

P: n/a
Jerry wrote:

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.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #10

P: n/a
On Tue, 25 Jan 2005 12:08:24 -0800, Hariprasad Govardhanam wrote:
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
Nov 14 '05 #11

P: n/a
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
Nov 14 '05 #12

P: n/a
Lawrence Kirby wrote:

On Tue, 25 Jan 2005 12:08:24 -0800, Hariprasad Govardhanam wrote:
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.


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.

--
pete
Nov 14 '05 #13

P: n/a
On Wed, 26 Jan 2005 15:02:27 +0000, pete wrote:
Lawrence Kirby wrote:

On Tue, 25 Jan 2005 12:08:24 -0800, Hariprasad Govardhanam wrote:
> 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.


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

Nov 14 '05 #14

P: n/a
On Wed, 26 Jan 2005 02:13:56 GMT, CBFalconer
<cb********@yahoo.com> wrote:
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
Nov 14 '05 #15

P: n/a
Chris Croughton <ch***@keristor.net> writes:
On Wed, 26 Jan 2005 02:13:56 GMT, CBFalconer
<cb********@yahoo.com> wrote:
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.


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.
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless
Nov 14 '05 #16

P: n/a
Lawrence Kirby 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.


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.

--
Best regards,
Andrey Tarasevich
Nov 14 '05 #17

P: n/a
Chris Croughton wrote:
<cb********@yahoo.com> wrote:
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.


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.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #18

P: n/a
Ben Pfaff <bl*@cs.stanford.edu> wrote:
Chris Croughton <ch***@keristor.net> writes:
On Wed, 26 Jan 2005 02:13:56 GMT, CBFalconer
<cb********@yahoo.com> wrote:
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.


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?

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Nov 14 '05 #19

P: n/a
S.Tobias wrote:
Would an malloc() which always returns NULL violate the Standard?


No.

--
pete
Nov 14 '05 #20

This discussion thread is closed

Replies have been disabled for this discussion.