On Wed, 28 Nov 2012 16:17:43 -0600
mdroth <mdr...@linux.vnet.ibm.com> wrote:
> On Wed, Nov 28, 2012 at 04:26:29PM -0500, Eric Blake wrote:
> >
> > > > > if (ferror(fh)) {
> > > > > + error_setg_errno(err, errno, "failed to read file");
> > > > > slog("guest-file-read failed, handle: %ld", handle);
> > > > > - error_set(err, QERR_QGA_COMMAND_FAILED, "fread()
> > > > > failed");
> > > > > } else {
> > > >
> > > > I'm not sure about relying on errno for FILE/f*() functions. C99
> > > > doesn't
> > > > appear to require setting it for implementations
> >
> > Correct that C99 doesn't require it, but POSIX _does_ require it.
> >
> > Windows is the biggest system out there where errno is unreliable after
> > failure on FILE operations (but as we DO support mingw, we ARE impacted
> > by the lameness of Microsoft's C library being C89 but not POSIX).
>
> Well, if it's primarilly an issue with windows, then I think we're okay
> relying on it for anything in qga/commands-posix.c at least, as those
> implementations get swapped out for the implementations in
> qga/commands-win32.o for win32/mingw builds. We'll need to be wary of
> this in the future if we end up sharing more code with the win32 port
> becomes more feature-full though.
>
> The comment elsewhere about setmntent() might still apply however.
Ok, so can I respin only 05/10?
> > > However, the other FILE functions seem safe to me. I'd be very
> > > surprised
> > > if some implementation doesn't set errno on fopen() failure for
> > > example
> >
> > Then you probably haven't experimented much with mingw :)
Nope. But I was referring to other unixes...
