Re: fgets() replacement
Eric Sosman <Eric.Sosman@su n.com> wrote:
: Paul D. Boyle wrote:
:> There was a recent thread in this group which talked about the
:> shortcomings of fgets(). I decided to try my hand at writing a
: First criticism: The function does too much. This is, of
: course, a matter of taste, but if the goal is "a replacement
: for fgets()" I think the validate() business is extraneous.
: (Even the `sz' parameter raises my eyebrows a little, albeit
: not a lot.)
: IMHO, a low-level library function should do one thing,
: do it well, and do it in a manner that facilitates combining
: it with other functions to create grander structures. Or as
: my old fencing coach used to admonish me when I got overenthused
: with tricky multiple-feint combinations: "Keep It Simple, Stupid."
I appreciate your criticisms. I especially agree that the 'int
(*validate)(int )' validation is, at best, misplaced to be used by this
low level function. I do like, however, the idea of having some
way of validating the input which can be simply plugged in without
messing with the main flow of the program.
: far towards the baroque. In effect, USER_DIALOG_H and the
: associated macros become part of the function's specification.
: That specification now encompasses one return value encoding
: three distinguishable states, four function arguments (two
: with usage rules not expressible to the compiler), and five
: macros. That strikes me as *way* too much for "a replacement
: for fgets()."
When I was writing the function my idea changed from returning
a size_t of the number of bytes read to an error code based
returned. I agree that this was muddled by "changing horses
in mid stream.
: ("All right, Smarty Pants, how would *you* do it?")
: Fair enough. Everybody, it seems, writes an fgets()
: replacement eventually, and here's the .h text for mine:
: char *getline(FILE *stream);
I did write another function with this prototype. Based on
how I will combine this with other input taking and parsing
functions, I am thinking of some thing like:
char *get_line( FILE *in, size_t *sz );
/* where 'sz' will "return" the number of bytes written */
or
size_t get_line( FILE *in, char **line );
I haven't decided yet which one to go with though.
:> #define ERROR_MEMORY (-1)
:> #define ERROR_ILLEGAL_C HAR (-2)
: Pointless parentheses.
I feel embarrassed. Shame is a good teacher. :-)
Again, thank-you for pointing out all the other shortcomings of
my function. I'll try again taking into account your feedback.
Regards,
Paul
--
Paul D. Boyle
boyle@laue.chem .ncsu.edu
North Carolina State University
Eric Sosman <Eric.Sosman@su n.com> wrote:
: Paul D. Boyle wrote:
:> There was a recent thread in this group which talked about the
:> shortcomings of fgets(). I decided to try my hand at writing a
: First criticism: The function does too much. This is, of
: course, a matter of taste, but if the goal is "a replacement
: for fgets()" I think the validate() business is extraneous.
: (Even the `sz' parameter raises my eyebrows a little, albeit
: not a lot.)
: IMHO, a low-level library function should do one thing,
: do it well, and do it in a manner that facilitates combining
: it with other functions to create grander structures. Or as
: my old fencing coach used to admonish me when I got overenthused
: with tricky multiple-feint combinations: "Keep It Simple, Stupid."
I appreciate your criticisms. I especially agree that the 'int
(*validate)(int )' validation is, at best, misplaced to be used by this
low level function. I do like, however, the idea of having some
way of validating the input which can be simply plugged in without
messing with the main flow of the program.
: far towards the baroque. In effect, USER_DIALOG_H and the
: associated macros become part of the function's specification.
: That specification now encompasses one return value encoding
: three distinguishable states, four function arguments (two
: with usage rules not expressible to the compiler), and five
: macros. That strikes me as *way* too much for "a replacement
: for fgets()."
When I was writing the function my idea changed from returning
a size_t of the number of bytes read to an error code based
returned. I agree that this was muddled by "changing horses
in mid stream.
: ("All right, Smarty Pants, how would *you* do it?")
: Fair enough. Everybody, it seems, writes an fgets()
: replacement eventually, and here's the .h text for mine:
: char *getline(FILE *stream);
I did write another function with this prototype. Based on
how I will combine this with other input taking and parsing
functions, I am thinking of some thing like:
char *get_line( FILE *in, size_t *sz );
/* where 'sz' will "return" the number of bytes written */
or
size_t get_line( FILE *in, char **line );
I haven't decided yet which one to go with though.
:> #define ERROR_MEMORY (-1)
:> #define ERROR_ILLEGAL_C HAR (-2)
: Pointless parentheses.
I feel embarrassed. Shame is a good teacher. :-)
Again, thank-you for pointing out all the other shortcomings of
my function. I'll try again taking into account your feedback.
Regards,
Paul
--
Paul D. Boyle
boyle@laue.chem .ncsu.edu
North Carolina State University
Comment