Re: malloc()/realloc() - have I got this right?
- From: CBFalconer <cbfalconer@xxxxxxxxx>
- Date: Fri, 30 May 2008 01:09:00 -0400
Richard Heathfield wrote:
CBFalconer said:.... snip ...
enum {OK = 0, NOMEM};
Are those the only two failure conditions? What about end of file?
Or a stream error? Why not make it possible to report those?
You didn't read the whole routine. It also returns EOF, which is
not defined here. I did point out that this listing omitted the
documentation etc.
The problem with this approach, as I have explained before, is
that it doesn't allow the caller to re-use an existing buffer.
If they try, the above line leaks the previous memory!
In your opinion. Similarly, never use malloc to set a pre-existing
pointer variable. Buffer reuse would require additional
parameters, and user confusion. Avoided.
ix = 0;
while ((EOF != (ch = getc(f))) && ('\n' != ch)) {
if (ix >= (cursize - 1)) { /* extend buffer */
cursize += DELTASIZE;
The problem with this approach is that it doesn't scale well.
Remember that stdin doesn't necessarily mean keyboard input. The
input might, for example, be coming from a very, very fast fixed
disk. Consider changing to an exponential approach, e.g. cursize
*= 2; (or even cursize *= 1.1 or something like that, which is
fineat if cursize starts with a value of least 10, which it does
in this case).
Which it is not intended to. It will work for any size, but is
optimized for those sizes expected as interactive input. Note that
the user can alter this part of the algorithm easily.
if (NULL == (temp = realloc(buffer, (size_t)cursize))) {
The problem with this approach is that it runs a significant risk
of exhausting memory without the programmer having any control over
this. Consider accepting a parameter that specifies the largest
buffer size this call is allowed to allocate.
The point is to avoid the need for any extra parameters and
associated confusion.
These are genuine concerns. Your continued failure to address them
is, of course, entirely your decision, but I am at a loss to
understand how you can possibly recommend such a function (which you
do, continually) whilst these flaws remain.
Yes, similarly it is a great evil to have file open functions,
since failure to close them may cause data loss. You are confusing
faults with design objectives. All these points have been answered
before, and you are perfectly free not to use ggets.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
.
- Follow-Ups:
- Re: malloc()/realloc() - have I got this right?
- From: Richard Heathfield
- Re: malloc()/realloc() - have I got this right?
- References:
- malloc()/realloc() - have I got this right?
- From: Dave
- Re: malloc()/realloc() - have I got this right?
- From: CBFalconer
- Re: malloc()/realloc() - have I got this right?
- From: Richard Heathfield
- Re: malloc()/realloc() - have I got this right?
- From: CBFalconer
- Re: malloc()/realloc() - have I got this right?
- From: Richard Heathfield
- malloc()/realloc() - have I got this right?
- Prev by Date: Re: "C vs java"
- Next by Date: Re: How to trace function calls?
- Previous by thread: Re: malloc()/realloc() - have I got this right?
- Next by thread: Re: malloc()/realloc() - have I got this right?
- Index(es):
Relevant Pages
|
