[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1464228 - in /subversion/trunk/subversion/libsvn_ra_serf: sb_bucket.c util.c

From: Greg Stein <gstein_at_gmail.com>
Date: Mon, 8 Apr 2013 00:34:55 -0400

On Apr 5, 2013 4:29 AM, "Daniel Shahaf" <danielsh_at_elego.de> wrote:
>
> Daniel Shahaf wrote on Fri, Apr 05, 2013 at 11:20:02 +0300:
> > Branko Čibej wrote on Fri, Apr 05, 2013 at 08:14:36 +0200:
> > > On 04.04.2013 23:17, Daniel Shahaf wrote:
> > > > FWIW, lgo's argument makes sense to me. I see no reason to remove
> > > > (void) casts that make our code more readable because some other
> > > > codebases use them to silence lint.
> > >
> > > My point is that they do not make the code more readable. Moreover:
when
> > > someone does turn on the extra compiler options to find places where
> > > return values are ignored, the (void)-cast calls will not be flagged.
> ...
> > > Who's to guarantee that the original author who decided to ignore the
> > > return value and dropped the (void) tu^Wbreadcrumb was right?
> >
> > The bug here is ignoring the return value. Whether the cast is present
> > or not is of secondary importance.
>
> Having the cast means two things:
>
> - It's easier for human readers to (a) see that there is a return value,
> and (b) that said return value is being intentionally ignored.
>
> - It may suppress some ($CC, lint, ...) warnings.
>
> Whether it was actually correct to ignore the return value is simply
> independent of the syntax that was used to ignore it.

Agreed. I want to know if/when we are consciously dropping a value on the
floor. As a reader of the source.

Thx,
-g
Received on 2013-04-08 06:35:29 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.