lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


What I meant is that null is special in the context of
fgets() even though the actual reading function (I
think most use fgetc) may or may not treat it
specially.

The definition of fgets() :

char *fgets(char *buf, int n, FILE *)

the return is a null terminated string, not the length
actually read. So any null in the input stream if not
treated specially would terminate the string and the
rest being lost(as there is no way to distinguish
whether that null is appended by fgets() or is in the
input).

So I would expect a 'better' fgets() would stop at
null as well as '\n'.

But using fgets() on input with embedded null is by
itself calling for trouble. Are there encoding
standard that allows null ? My understanding is that
utf8 doesn't.

--- Shane Lee <shaneplee@gmail.com> wrote:

> Gary,
> 
>     I am curious, can you tell me of an example of
> where a NULL
> character is interpreted by fgets() as an ending
> character? I
> understand that reading in NULL (or '\0' in this
> case) directly to the
> input buffer would result in most cases of having
> the new buffer
> appear to end for any upcoming manipulations (i.e.
> any function
> reading the resulting string would assume that the
> string ends at the
> first '\0' character it encounters), however I don't
> believe fgets
> cares about the NULL character any more than any
> other character
> except for '\n', though I haven't looked at the
> source in a while. In
> any case, in what sort of file would a NULL
> character appear that
> could not be interpreted as EOF and yet still have
> data following it?
> 
> On Sun, Apr 13, 2008 at 8:09 PM, gary ng
> <garyng2000@yahoo.com> wrote:
> >
> >  --- Shmuel Zeigerman <shmuz@actcom.co.il> wrote:
> >  > Here is an fgets specification from The Open
> Group:
> >  >
> >  > > The fgets() function shall read bytes from
> stream
> >  > into the array
> >  > > pointed to by s, until n-1 bytes are read, or
> a
> >  > <newline> is read
> >  > > and transferred to s, or an end-of-file
> condition
> >  > is encountered.
> >  > > The string is then terminated with a null
> byte.
> >  >
> >  >  From this specification, it is quite obvious
> that
> >  > only <newline> is
> >  > special in the input stream.
> >  >
> >  I have a very different reading. In fact, I think
> null
> >  is a special case as C strings are null
> terminated.
> >  Thus it implicitly means that fgets() would stop
> at
> >  null OR '\n'. Especially the last line where it
> said a
> >  final NULL would be appended.
> >
> >  Think if it doesn't stop at NULL of the input,
> then
> >  anything beyond that is still invisible as caller
> of
> >  this function expects the string to be a C
> string(i.e.
> >  null terminated). So what is the point to read
> beyond
> >  that ? If fact, without reading beyond that, a
> loop
> >  can still read all the contents(sans NULL and \n)
> but
> >  that still matches the 'lines of string'
> expectation
> >  in C.
> >
> >
> > 
> __________________________________________________
> >  Do You Yahoo!?
> >  Tired of spam?  Yahoo! Mail has the best spam
> protection around
> >  http://mail.yahoo.com
> >
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com