So if one of those fgetc calls fails (say the third) is the buffer guaranteed to be unchanged? Or will the characters read so far be in the buffer? The patch submitted assumes that the buffer is unchanged, but I do not think there is a guarantee of this. Checking the return value seems to be the safest check of success.
On 23 December 2011 11:27, Rich Felker <[email protected]> wrote: > On Wed, Dec 21, 2011 at 10:53:30AM +1000, Daniel Wainwright wrote: > > I don't believe that buf is guaranteed to be unchanged if there is an > error > > in fgets, according to the man page the contents are "indeterminate". So > it > > may write some characters to buf and not null-terminate it. So if you're > > only assuming fgets conforms to the spec I think checking the return > value > > is safer, or is this an implementation detail of this fgets? > > Can you show me anywhere the C standard allows crap to be written to > the buffer? fgets is specified very simply as if by a sequence of > calls to fgetc filling subsequent positions of the pointed-to array. > It can't act outside of those bounds... > > Rich > _______________________________________________ > uClibc mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc > -- Regards, Daniel Wainwright _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
