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.
19  26644 
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.
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
"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
"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
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
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.
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" <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
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
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
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 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
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
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
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
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
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
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`
S.Tobias wrote: Would an malloc() which always returns NULL violate the Standard?
No.
--
pete This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Paul |
last post by:
Hi,
I'm using TikiWiki and was using its file upload feature, trying to
upload a 2MB file. I get this error:
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to
allocate...
|
by: Joerg Schwerdtfeger |
last post by:
Hi folks,
how can I determine the total main-memory size and the size of free
memory available in bytes?
I tried to use mallinfo() from malloc.h - resulting some strange values
in Windows...
|
by: keredil |
last post by:
Hi,
Will the memory allocated by malloc get released when program exits?
I guess it will since when the program exits, the OS will free all the
memory (global, stack, heap) used by this...
|
by: lovecreatesbeauty |
last post by:
Hello experts,
1. Does C guarantee the data layout of the memory allocated by malloc
function on the heap. I mean, for example, if I allocate a array of 100
elements of structure, can I always...
|
by: mast2as |
last post by:
This question has been posted to this forum before and I read the
thread but found that the answers were perhaps imcomplete, so I am
trying again.
Whenever I am creating objects I would like to...
|
by: Kimmo Laine |
last post by:
Hi!
We've encountered a strange problem concerning memory usage. In the previous
install the maximum memory amount per page was limited to 8 MB and it was
never reached. Now, after upgrading...
|
by: Abhishek Bhatt |
last post by:
I am using "msgBox" to show a message to the user. The problem is that the message is so big that 't's getting truncated in between. Is there any limitation on the maximum message length? Is there...
|
by: anon856525 |
last post by:
Hi
I recently downloaded Turbo C v2.01 from the borland web site where
its being given out for free. Has anyone else tried this?
Ive been using it for some months now and hav'nt noted any...
|
by: jty0734 |
last post by:
i don't know what input size of string is.
so i can't gets inputsize before malloc function.
i want determine the size of malloc without get inputsize in advance.
how to deal with it?
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
