1 Oct
2002
1 Oct
'02
11:47 p.m.
At 01:24 morn 10/1/02 -0700, Satya wrote:
which is irrelevant. What makes you /not/ to define a array sufficiently
large as per your needs before hand? In both cases someone who does /not/
heed your needs [or simply is trying to be bad] may pour in more data then
there is space available for. Malloc does not have a predictive logic
built into it by which it keeps up with the memory requirements. It just
allocates what you as it to. The mechanism has to be provided by the
program logic, which was the point of the last communique.
I was not alluding to any book.
You have very /conveniently/ snipped off portions which state the same
thing. There was a line above - "Malloc allows you to have sophisticated
mechanisms where you may limit size of buffer to only the size of free
memory available from the OS." Malloc is a standard function for
allocating memory dynamically. But it by itself does /not/ solve the
overflow problem - which is what you insinuated. One has to have a
mechanism for having a truly flexible input buffer. And the one I
mentioned may not be a good method - it was just a method to support a point.
quasi
malloc you
allocate /limited/ memory too. There is /no/ way to prevent you
from overflowing an allocated buffer if you so wish.
I guess I should say that dynamic memory allocation, by definition, allows
you to allocate as much memory as you need at runtime. >[..C for
dummies example]
Haven't read that. It's a fairly obvious example. inefficient.
Someone else can have a say on this maybe. For truly
flexible storage a linked lists of buffers may be more the way to go.
Like for a text editor? Yeah, and you're still mallocing the structs.