This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: About fwrite(s, 0, 1, fp)
Wolfram Gloger <wmglo@dent.med.uni-muenchen.de> writes:
|> > > > I am not sure about it. If everyone else returns 0, it doesn't make
|> > > > glibc look good. Can someone check VC++?
|> >
|> > On the contrary! The C standard is very clearly worded on this point, and
|> > our implementation is definitely correct. This not the first time by far
|> > that GNU libc has been the only library around to actually conform to the
|> > standards, and the commercial vendors slowly come around.
|>
|> I agree with you that the C standard is the authorative resource here.
|> However, I just checked the Single Unix specification
|> (http://www.rdg.opengroup.org:80/onlinepubs/7908799/), and discovered
|> for fwrite():
|>
|> The fwrite() function returns the number of members
|> successfully written, which may be less than nitems if a write error
|> ^ note no `only' here!
|> is encountered. If size or nitems is 0, fwrite() returns 0 and the
|> state of the stream remains unchanged. Otherwise, if a write error
|> occurs, the error indicator for the stream is set and errno is set
|> to indicate the error.
|>
|> So it appears to me that there is a conflict of standards here :-(.
|> What can be done to resolve such a conflict ? Is it advisable to
|> contact the Open Group about it ?
Note that this standard contradicts itself in the description of fread:
Upon successful completion, fread() returns the number of members
successfully read which is less than nitems only if a read error or
^^^^
end-of-file is encountered. If size or nitems is 0, fread() returns 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So i'd say the bug is on the Open Group.
--
Andreas Schwab "And now for something
schwab@issan.cs.uni-dortmund.de completely different"
schwab@gnu.org