Re: [Qemu-devel] [PATCH v3] avoid compilation warning/errors on up to date compilers/glibc

[Luiz Capitulino <lcapitulino@redhat.com>]

On Wed, 17 Jun 2009 20:41:14 +0200
"Jean-Christophe Dubois" <jcd@tribudubois.net> wrote:

> Le mercredi 17 juin 2009 16:03:51, vous avez écrit :
> > > > This is no more correct than before.  read() can return EINTR
> > > > and that should be handled appropriately.  Elsewhere, read()
> > > > can return partial results and we ought to handle that properly.
> > >
> > > It handles all cases except EINTR. And in the actual code base
> > > EINTR and __all other__ error cases are not handled. So as of
> > > today EINTR is not handled propely (as well as all other error
> > > cases). So this consider EINTR as an error when it could be
> > > handled in a nicer way. Previously no ERRORS were considered as
> > > an error. What is best?
> >
> > The original is the lesser wevil because it is obviously wrong.
> > Your patch looks like it does error handling and avoids generates
> > warnings, but still does not work correctty.
> >
> > > > Using -D_FORTIFY_SOURCES=0 will eliminate these warnings.  If
> > > > we're going to fix these things, we should fix them properly.
> > >
> > > It just hides the problem and fix nothing but the compilation.
> >
> > Your patch just makes the bug more subtle and harder to spot.
> 
> I guess this is a matter of point of view. 

 I don't think it's a point of view, today we have a warning and we
know something is not ok. With this patch we won't have the warning
anymore but the solution is not what it should be.

 Can't we have wrappers to read() and write() that does the right
thing and use them everywhere?

> Is it harder to find a bug when:
> 1) you are silencing compilation warning/errors AND ignoring all
> runtime errors (also silencing future warnings/errors).

 My impression is that Anthony's tip is for you get it built, not
a final solution to the problem.

> or 2) You are considering recoverable errors as non recoverable
> errors.

 qemu_read() and qemu_write() could handle both.

> BTW are you sure that EINTR and EAGAIN are correctly handled all over
> the source code? What about partial read/write?

 I have no idea, but if they are not they should be fixed then.