[PATCH 10/10] clients: Silence 2x gcc 4.6.3 "warn_unused_result" compiler warnings

[Kristian Høgsberg]

On Sun, Jul 08, 2012 at 10:58:35AM +0300, Pekka Paalanen wrote:
> On Sun,  8 Jul 2012 03:03:47 +0200
> Martin Olsson <martin at minimum.se> wrote:
> 
> > window.c:1173:6: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result]
> > desktop-shell.c:305:6: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result]
> > ---
> >  clients/desktop-shell.c |    3 ++-
> >  clients/window.c        |    3 ++-
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/clients/desktop-shell.c b/clients/desktop-shell.c
> > index 0605f84..fbc0604 100644
> > --- a/clients/desktop-shell.c
> > +++ b/clients/desktop-shell.c
> > @@ -302,7 +302,8 @@ clock_func(struct task *task, uint32_t events)
> >  		container_of(task, struct panel_clock, clock_task);
> >  	uint64_t exp;
> >  
> > -	read(clock->clock_fd, &exp, sizeof exp);
> > +	if (read(clock->clock_fd, &exp, sizeof exp) != sizeof exp)
> > +		abort();
> >  	widget_schedule_redraw(clock->widget);
> >  }
> >  
> > diff --git a/clients/window.c b/clients/window.c
> > index f81d06f..92f3fd5 100644
> > --- a/clients/window.c
> > +++ b/clients/window.c
> > @@ -1170,7 +1170,8 @@ tooltip_func(struct task *task, uint32_t events)
> >  		container_of(task, struct tooltip, tooltip_task);
> >  	uint64_t exp;
> >  
> > -	read(tooltip->tooltip_fd, &exp, sizeof (uint64_t));
> > +	if (read(tooltip->tooltip_fd, &exp, sizeof (uint64_t)) != sizeof (uint64_t))
> > +		abort();
> >  	window_create_tooltip(tooltip);
> >  }
> 
> Hi,
> 
> I think this needs more work, abort() is too harsh here.
> Failing the read is not fatal, at most it deserves a
> warning message printed.
> 
> The fd is being read, so that the fd would become non-readable
> again. If and when the fd is readable, the event loop calls these
> clock_func() or tooltip_func(). We want to read out the datum
> that triggered this, and only this, callback. Timerfd defines that
> the datum is a single uint64_t.

Failing the read here should never happen (we only get here when the
fd is readable, and there's no hw involved or anything else that might
fail.  If this fails, something is really broken somewhere and might
as well abort.

Kristian