Re: Question regarding fgets and new lines
- From: Keith Thompson <kst-u@xxxxxxx>
- Date: Mon, 27 Nov 2006 23:44:20 GMT
CBFalconer <cbfalconer@xxxxxxxxx> writes:
Eric Sosman wrote:
... snip ...
FWIW, I took a somewhat different tack in my own gets()
replacement (I guess everybody writes one, sooner or later).
Mine follows the precedent of things like getenv(): the returned
pointer is only valid until the next call, when the buffer it
points to may be overwritten and/or moved or freed.
This approach has some disadvantages: for example, it would
be a pain to make it thread-friendly. On the other hand, it
localizes all the memory management inside the function, and the
signature `char *getline(FILE*)' is simple enough that even I can
remember it. (The older and feebler my gray cells get, the more
I value simplicity ...)
When I designed ggets I considered that signature, but I could see
no way of returning appropriate errors for both FILE problems, EOF,
and memory allocation problems.
I second the motion about easily remembered signatures.
Well, you *could* return as many unique error conditions as you like
with a simple char* return value:
const char *const gl_EOF = "getline: EOF";
const char *const gl_io_error = "getline: I/O error";
const char *const gl_malloc_failed = "getline: malloc failed";
...
Each error code is a unique pointer value. One problem is that
there's no good way to detect success other than by comparing the
result to each possible error code (a set that can easily change in
later revisions of the function); this can be alleviated somewhat by
putting all the error codes into an array, but it's still inconvenient
for the user. You could provide an auxiliary function that tells you
whether the char* value returned by getline() points to an error
message or not.
Another drawback is that you can't return both error information and
actual data.
But if the user forgets to check the result, the value returned looks
like an error message which could make it easier to track down bugs.
Another approach is to implement something resembling errno, but that
can make it difficult to tie an error to a specific call.
--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <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.
.
- Follow-Ups:
- Re: Question regarding fgets and new lines
- From: Eric Sosman
- Re: Question regarding fgets and new lines
- References:
- Question regarding fgets and new lines
- From: mellyshum123
- Re: Question regarding fgets and new lines
- From: Eric Sosman
- Re: Question regarding fgets and new lines
- From: CBFalconer
- Re: Question regarding fgets and new lines
- From: Roland Pibinger
- Re: Question regarding fgets and new lines
- From: CBFalconer
- Re: Question regarding fgets and new lines
- From: Eric Sosman
- Re: Question regarding fgets and new lines
- From: CBFalconer
- Question regarding fgets and new lines
- Prev by Date: Re: screen clearing in ANSI C
- Next by Date: Re: Most Interesting Bug Track Down
- Previous by thread: Re: Question regarding fgets and new lines
- Next by thread: Re: Question regarding fgets and new lines
- Index(es):
Relevant Pages
|
|
