1 Oct
2002
1 Oct
'02
11:48 p.m.
At 01:56 morn 10/1/02 -0700, S wrote:
--- q u a s i <quasar(a)vsnl.net> wrote:
^^^^^
[cannot really do that, please be more spoon feedish. - consider me a dummy
as Satya did]
I would be interested in knowing some of the 'plethora' of problems
mentioned about. as for the speed issue, I would be mucho obliged if you
could suggest a method which is faster.
For truly
flexible storage a linked lists of buffers may be more the way to go.
hmm... not really.. plethora of known problems here unless u r careful
(think speed of access.. ) if u can use then go for BOOST library (C++). Re-iterating the point .. Again this is for flexible
storage.. It has
nothing to do with buffer overflow problem. That is a coding issue.
both are related. If I am supposed to take input which is of undetermined
length & I dont want to miss any bytes then the above is relevant. How in
the name of Gawd do you say it has nothing to do with buffer overflows is
beyond me. They occur because of predicted size of expected input. Of
course the methods of avoiding that are a design[1] issue.
Just as an eg., windows CRT in scanf, gets, uses a
simple algorithm.
Allocate 4096 byte buffer array. Read inputs in chunks of 4096 bytes and
keep passing!
keep passing where? To memory space being dynamically added? Memory space
which can be called a buffer? Memory chunks which are in someway linked [to
give the impression of one large chunk]? If you look carefully at what I
wrote you may see that these two are approximately the same things.
[1] - Design as in problem solution. Coding is just translation - mundane
& irrelevant.
quasi