the maximum memory size allowed in malloc

Discussion in 'C Programming' started by Jerry, Jan 25, 2005.

  1. Jerry

    Jerry Guest

    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.
    Jerry, Jan 25, 2005
    #1
    1. Advertising

  2. 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.
    Hariprasad Govardhanam, Jan 25, 2005
    #2
    1. Advertising

  3. 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
    those who know me have no need of my name, Jan 25, 2005
    #3
  4. Jerry

    Mike Wahler Guest

    "Jerry" <> wrote in message
    news:...
    > 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, Jan 25, 2005
    #4
  5. Jerry

    Mike Wahler Guest

    "Hariprasad Govardhanam" <> wrote in message
    news:...
    > 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
    Mike Wahler, Jan 25, 2005
    #5
  6. 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
    Andrey Tarasevich, Jan 25, 2005
    #6
  7. those who know me have no need of my name <> 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) <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, Jan 25, 2005
    #7
  8. Jerry

    italy Guest

    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
    italy, Jan 25, 2005
    #8
  9. Jerry

    Mike Wahler Guest

    "italy" <> wrote in message
    news:...
    > 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
    Mike Wahler, Jan 26, 2005
    #9
  10. Jerry

    CBFalconer Guest

    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
    CBFalconer, Jan 26, 2005
    #10
  11. 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
    Lawrence Kirby, Jan 26, 2005
    #11
  12. 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
    Lawrence Kirby, Jan 26, 2005
    #12
  13. Jerry

    pete Guest

    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
    pete, Jan 26, 2005
    #13
  14. 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
    Lawrence Kirby, Jan 26, 2005
    #14
  15. On Wed, 26 Jan 2005 02:13:56 GMT, CBFalconer
    <> 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
    Chris Croughton, Jan 26, 2005
    #15
  16. Jerry

    Ben Pfaff Guest

    Chris Croughton <> writes:

    > On Wed, 26 Jan 2005 02:13:56 GMT, CBFalconer
    > <> 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
    Ben Pfaff, Jan 26, 2005
    #16
  17. 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
    Andrey Tarasevich, Jan 26, 2005
    #17
  18. Jerry

    CBFalconer Guest

    Chris Croughton wrote:
    > <> 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
    CBFalconer, Jan 26, 2005
    #18
  19. Jerry

    S.Tobias Guest

    Ben Pfaff <> wrote:
    > Chris Croughton <> writes:


    > > On Wed, 26 Jan 2005 02:13:56 GMT, CBFalconer
    > > <> 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 LID | sed s/[[:upper:]]//g`
    S.Tobias, Jan 26, 2005
    #19
  20. Jerry

    pete Guest

    S.Tobias wrote:

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


    No.

    --
    pete
    pete, Jan 27, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. J055
    Replies:
    3
    Views:
    1,325
    Steven Cheng[MSFT]
    Jul 5, 2006
  2. Peter
    Replies:
    34
    Views:
    1,946
    Richard Tobin
    Oct 22, 2004
  3. Gene
    Replies:
    0
    Views:
    448
  4. V.Subramanian, India

    malloc and maximum size

    V.Subramanian, India, Oct 14, 2011, in forum: C Programming
    Replies:
    56
    Views:
    2,393
    Tim Rentsch
    Feb 1, 2012
  5. phanhuyich
    Replies:
    4
    Views:
    268
Loading...

Share This Page