Variable-sized lines of text in linked list

[CBFalconer]

CBFalconer said:
.... snip ...


Okay, here are the issues as I see them:

1) the function doesn't allow the user to minimise memory
management issues by re-using existing buffers.
2) the function doesn't allow the user to resist
denial-of-memory attacks.
3) the function doesn't allow the user to specify whether the
buffer should be resized to fit.
4) the function documentation doesn't mention any of these
problems.
5) in Usenet articles where you recommend ggets, you don't
mention any of these problems.

Now how does that differ from use of malloc, calloc, or realloc?
For example, any program (or routine) that collects data will
malloc something and add it to a list, tree, or something. Sooner
or later that will overflow, and jam the malloc system. If the
program doesn't free that memory, but continues, the
denial-of=memory works. Same here. Note that the ggets caller
knows why the function returned.

I covered your complaint about lack of explanation with ggets.h
extract. It is hard to use the system without the .h file.

 

[ymuntyan]

CBFalconer said:





Okay, here are the issues as I see them:

1) the function doesn't allow the user to minimise memory management issues
by re-using existing buffers.
2) the function doesn't allow the user to resist denial-of-memory attacks.
3) the function doesn't allow the user to specify whether the buffer should
be resized to fit.
4) the function documentation doesn't mention any of these problems.
5) in Usenet articles where you recommend ggets, you don't mention any of
these problems.

In other words:

0) Your ggets is shorter than my ggets, because my ggets
is described in great detail as I am a Great Teacher.
And stuff. Should I have not had my ggets, I would claim
that your ggets is perfect because it perfectly works as
documented.

 

[Richard Heathfield]

CBFalconer said:

Now how does that differ from use of malloc, calloc, or realloc?

And in other surveillance satellites have reported that they have
detected a low-denomination coin leaving Earth's atmosphere. It appears to
be accelerating.

 

[Richard Heathfield]

(e-mail address removed) said:

In other words:

0) Your ggets is shorter than my ggets, because my ggets
is described in great detail as I am a Great Teacher.
And stuff. Should I have not had my ggets, I would claim
that your ggets is perfect because it perfectly works as
documented.

On the contrary. If Chuck fixes the problems inherent in his design, I
shall be (among) the first to recommend his solution. This isn't a matter
of personality, but of good vs. bad design. As it happens, I *don't*
currently recommend my own fgetdata function here because someone reported
that it incorporates a bad design decision (it ought to return EOF on
EOF!) and I haven't yet got around to fixing the code. Apathy rules OK.

 

[ymuntyan]

(e-mail address removed) said:




On the contrary. If Chuck fixes the problems inherent in his design, I
shall be (among) the first to recommend his solution. This isn't a matter
of personality, but of good vs. bad design.

strncpy

 

[Richard Heathfield]

(e-mail address removed) said:

strncpy

What about it? I have in the past argued against its use (as a "safe"
replacement for strcpy, which it is not) and yet /for/ its use on
occasions where it is appropriate (which don't happen often, but do
happen).

By the way, if I attacked you like you attack me, you'd be complaining of
harassment by now. There's no reason to it, it achieves nothing, and it
makes it much harder for us to be friends. Please stop. Thank you.

 

[pete]

Bartc wrote:

Reading an entire file into memory is an admirable idea,
but is frowned on in this newsgroup for various reasons:

Are you sure?
I've never noticed.

the size of a file is impossible to determine,
or could change while you're reading the file, or because it
might be a 100GB monster you
therefore should never attempt this even for tiny files.

That doesn't mean you shouldn't do it;
just keep quiet about it here

On the other hand,
you might know that your input files are small
and then there's no reason not to attempt to read one into a list.

 

[Dann Corbit]

Are you sure?
I've never noticed.

The typical solution for this is demand paging. I wrote a C routine to do
this sort of thing around 1987. Today, many modern operating systems can do
this sort of thing for you with very little fuss and muss on your part.

On the other hand,
you might know that your input files are small
and then there's no reason not to attempt to read one into a list.

Or you can use an OS specific function to get an estimate of the file size
and use that information to decide upon a strategy.