Re: removing newline character from the buffer read by fgets

junky_fellow@xxxxxxxxxxx said:



On Nov 28, 3:27 pm, Richard Heathfield <r...@xxxxxxxxxxxxxxx> wrote:
junky_fel...@xxxxxxxxxxx said:

On Nov 28, 1:59 pm, Richard Heathfield wrote:
The principal objection I have to your code is that it fails to
provide a way to distinguish between a line that has been read
completely and a line that has been read only partially because of
insufficient space in the buffer.

For that I would change the function to return the number of bytes
read.That is a reasonable approach. I would suggest a size_t type for
this. You
might reasonably reserve 0 for an exceptional condition, leaving the user
to enquire of ferror() to find out whether Something Really Bad happened
or whether the routine simply couldn't find any data to stuff into the
buffer (i.e. encountered EOF on the first getc call).


Using 0 or some other value (negative value) for an exceptional
condition
is a good idea. thanks for that.

0, if you're using an unsigned type such as size_t.

Regarding "size_t", I used the type "int" for "bytes_read" as its value
will
never be greater than "n". The type of "n" is "int", so I thought
"bytes_read"
should also be "int".

Why not change n's type to size_t? After all, it represents the size of an
object, does it not?


Is there any special reason for using size_t for "bytes_read" ?

It's an unsigned integer type that is guaranteed to be able to store the
largest possible object size, whereas int is not.

See also the following standard library functions, which use size_t for much
the same reason:

bsearch, calloc, fread, fwrite, malloc, memchr, memcmp, memcpy, memmove,
memset, qsort, realloc, setvbuf, strftime, strlen, strncat, strncmp,
strncpy, and no doubt I missed one or two.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
.

Relevant Pages

  • Re: O_DIRECT question
    ... the disk isn't a good idea IMHO. ... There is a reason that read and write return the ... fsync between both sets of writes, but that will flush any other ... The large buffer size really has little to do with it, ...
    (Linux-Kernel)
  • Re: [Newbie Question] Magic Numbers dangerous?
    ... > reason can be documented with a well-chosen variable name. ... it's generally a matter of taking a guess. ... where memory is typically allocated in pages of a power of two in size. ... ideal buffer sizes, then most of us haven't yet been informed. ...
    (comp.lang.java.programmer)
  • Re: sharing memory with non-children
    ... > program that uses shared memory and semaphores to make a pseudo-pipe ... If you STREAM the data from one process to the another, ... necessarily need a big buffer. ... > is no good reason to do so. ...
    (comp.unix.programmer)
  • Re: [Newbie Question] Magic Numbers dangerous?
    ... >> reason can be documented with a well-chosen variable name. ... > buffer sizes, it's generally a matter of taking a guess. ... > the guess is a power of two, because it works better with MMU/paging ...
    (comp.lang.java.programmer)
  • Re: viewing files in a directory
    ... PS - the reason I did show that is because you can take the prologue code ... before the do-while loop and make necessary adjustments for it to recursive ... > so you can give the buffer address. ...
    (microsoft.public.vc.mfc)