Re: failure to build due to ignoring fwrite() result

Here's a proposed rewrite that tries to take all the comments in mind, while trying to improve the prose a bit. rms was fine with the proposed change to standards.texi. I installed it. Thanks.

Re: failure to build due to ignoring fwrite() result

Here's a proposed rewrite that tries to take all the comments in mind, while trying to improve the prose a bit. FWIW, this standards.texi change looked good to me. I sent it to rms. Thanks to all.

Re: failure to build due to ignoring fwrite() result

Hi, On Thu, Sep 2, 2010 at 9:23 AM, Paul Eggert wrote: > Bruno's proposed changes are mostly good, but I have a few quibbles: > >> +Don't make the program ugly just to placate warnings from tools other >> +than those that you use on a daily basis. > > This isn't quite right.  Suppose a programmer

Re: failure to build due to ignoring fwrite() result

Bruno's proposed changes are mostly good, but I have a few quibbles: > +Don't make the program ugly just to placate warnings from tools other > +than those that you use on a daily basis. This isn't quite right. Suppose a programmer uses 'lint' on a daily basis? They they can make a program ugly

Re: failure to build due to ignoring fwrite() result

Hi Bruno, FWIW I’d prefer more “neutral” wording, which couldn’t be interpreted as discouraging use of static analysis tools, and at the same time try to discuss trade-offs rather than taste: Bruno Haible writes: > --- doc/standards.texi.orig Wed Sep 1 01:25:45 2010 > +++ doc/standards.texi

Re: failure to build due to ignoring fwrite() result

Karl, all, > @pindex lint > ! Don't make the program ugly to placate @code{lint}. Please don't insert any > ! casts to @code{void}. Zero without a cast is perfectly fine as a null > ! pointer constant, except when calling a varargs function. Here is a proposed wording that - acknowledges th

Re: failure to build due to ignoring fwrite() result

On 08/31/2010 05:34 AM, Bruce Korb wrote: 1. GCC needs to relax the constraint that functions marked with warn-unused-result cause warnings when the result_is_ handled with a void cast. This is done by design (I disagree, but this is not going to change). This is the only reason wh

Re: failure to build due to ignoring fwrite() result

On 08/31/2010 03:24 AM, Bruno Haible wrote: Hi Paul, + @pindex gcc @pindex lint ! @pindex valgrind ! Don't make the program ugly to placate @code{gcc -Wall}, -Wextra should fix Bruno's valid complaint. @code{lint}, ! @code{valgrind}, or other software analysis tools. These tools can ! h

Re: failure to build due to ignoring fwrite() result

Hi, On 08/30/10 18:24, Bruno Haible wrote: > Hi Paul, > >> + @pindex gcc >> @pindex lint >> ! @pindex valgrind >> ! Don't make the program ugly to placate @code{gcc -Wall}, @code{lint}, >> ! @code{valgrind}, or other software analysis tools. These tools can >> ! help find bugs, but they can al

Re: failure to build due to ignoring fwrite() result

Hi Paul, > + @pindex gcc > @pindex lint > ! @pindex valgrind > ! Don't make the program ugly to placate @code{gcc -Wall}, @code{lint}, > ! @code{valgrind}, or other software analysis tools. These tools can > ! help find bugs, but they can also generate false alarms for constructs > ! that they

Re: failure to build due to ignoring fwrite() result

(adding to the To: list) Here is a proposed patch that follows up on the discussion about "(void) fwrite (...)" and "ignore_value (fwrite (...))" that is rooted at . This doesn't capture all the comments there (as they don't all

Re: failure to build due to ignoring fwrite() result

And it would be better to update the GCS so that they give reasonable advice also for today's situations, Yes, I agree. Can you propose a patch to bug-standards? Overall, the point of rms's comments here is/was to state what we all agree with: we want useful warnings, and don't want us

Re: failure to build due to ignoring fwrite() result

Hi Paul, > In controversial areas like this, we should look to the GNU coding standards > for advice, and they state that one shouldn't cast to void, or use > similar measures merely to satisfy a lint checker. Let me quote the GCS explicitly: "Don't make the program ugly to placate `lint'. P

Re: failure to build due to ignoring fwrite() result

Eric Blake wrote: > On 08/30/2010 01:59 PM, Jim Meyering wrote: >>> As I said, checking ferror() at the end of a write-to-log session then >>> triggering an event. "good enough" even if not excruciatingly perfect. >> >> Checking ferror is good enough as long as you rely only on fwrite, and >> not

Re: failure to build due to ignoring fwrite() result

On Mon, Aug 30, 2010 at 1:57 PM, Jim Meyering wrote: > That said, if there is a way to tell gcc to ignore > a particular otherwise-offending WUR warning without > cluttering up our code, I'd be interested. That a simple cast to void says that part of the issue is a gcc bug. Anyplace where a compi

Re: failure to build due to ignoring fwrite() result

Paul Eggert wrote: > On 08/30/10 12:52, Jim Meyering wrote: >> However, for the vast majority of the functions marked with this >> attribute, ignoring the return value really is a bug in all but a >> very small fraction of the use cases. > > That may well be, but that's not the issue. The issue is

Re: failure to build due to ignoring fwrite() result

On 08/30/2010 02:48 PM, Paul Eggert wrote: On 08/30/10 12:52, Jim Meyering wrote: However, for the vast majority of the functions marked with this attribute, ignoring the return value really is a bug in all but a very small fraction of the use cases. That may well be, but that's not the issue.

Re: failure to build due to ignoring fwrite() result

Eric Blake wrote: ... > All the more reason to have an open bug against glibc ... I've just filed this: http://sourceware.org/bugzilla/show_bug.cgi?id=11959 fwrite must not be declared with the warn_unused_result attribute

Re: failure to build due to ignoring fwrite() result

On 08/30/10 12:52, Jim Meyering wrote: > However, for the vast majority of the functions marked with this > attribute, ignoring the return value really is a bug in all but a > very small fraction of the use cases. That may well be, but that's not the issue. The issue is whether the cost of using

Re: failure to build due to ignoring fwrite() result

Wow. I didn't mean to touch off a discussion quite this long. Insofar as I'm involved: if Bruce is fairly sure the code does what he intends, I'm happy with a working build, and, optionally, a way of not being bothered by "false-positive" warnings during the compile. Quite honestly, on a Gentoo

Re: failure to build due to ignoring fwrite() result

On 08/30/2010 02:13 PM, Eric Blake wrote: All the more reason to have an open bug against glibc and have Ulrich defend why fwrite is marked __wuc but not fputc (and hopefully, he is smart enough to remove __wuc from fwrite, rather than making things worse by adding it to fputc). Oops - __wur (s

Re: failure to build due to ignoring fwrite() result

On 08/30/2010 02:01 PM, Bruce Korb wrote: Meanwhile, gcc has added a new warning suppression option, --no-warn-unused-result (or very similar). Yes, that's exactly Paul's suggestion - disable the gcc warning, and lose all the benefits it provides on other functions. I don't know so much abo

Re: failure to build due to ignoring fwrite() result

On 08/30/2010 01:59 PM, Jim Meyering wrote: As I said, checking ferror() at the end of a write-to-log session then triggering an event. "good enough" even if not excruciatingly perfect. Checking ferror is good enough as long as you rely only on fwrite, and not say, *printf. Some *printf failu

Re: failure to build due to ignoring fwrite() result

On 08/30/2010 01:52 PM, Jim Meyering wrote: fwrite is an exception in that its value really is ignorable, if you know what you're doing. Hence, the warn_unused_result attribute on its declaration is the problem, not gcc, and not the ignore-value module. Agreed. Do we have an open bugzilla aga

Re: failure to build due to ignoring fwrite() result

Paul Eggert wrote: > On 08/30/10 08:27, Eric Blake wrote: >> On 08/30/2010 08:29 AM, Bruce Korb wrote: >>> Every now and then, I'm thumped on the head by something fairly silly. >>> This warning is quite silly: >>> >>> (void)fwrite(...) >> >> Gnulib has the ignore-value module for places where

Re: failure to build due to ignoring fwrite() result

Howdy, another penny or two: On Mon, Aug 30, 2010 at 12:52 PM, Jim Meyering wrote: > Hi Paul, > The solution here could be to make gnulib provide a better declaration of > fwrite: one without the offending attribute.  Deprecating ignore-value or > somehow disabling all warn_unused_result attribu

Re: failure to build due to ignoring fwrite() result

Bruce Korb wrote: > On Mon, Aug 30, 2010 at 9:59 AM, Jim Meyering wrote: >> Bruce Korb wrote: >>> Hi Jim, >>> >>> On Mon, Aug 30, 2010 at 9:26 AM, Jim Meyering wrote: I don't like the length of "ignore_value" either, but think of that as a feature, not a problem.  It's more of an auto-r

Re: failure to build due to ignoring fwrite() result

Hello, * Paul Eggert wrote on Mon, Aug 30, 2010 at 09:17:34PM CEST: > In controversial areas like this, we should look to the GNU coding standards > for advice, and they state that one shouldn't cast to void, or use > similar measures merely to satisfy a lint checker. So I suggest that we > not u

Re: failure to build due to ignoring fwrite() result

On 08/30/10 08:27, Eric Blake wrote: > On 08/30/2010 08:29 AM, Bruce Korb wrote: >> Every now and then, I'm thumped on the head by something fairly silly. >> This warning is quite silly: >> >> (void)fwrite(...) > > Gnulib has the ignore-value module for places where casting to void is > insuff

Re: failure to build due to ignoring fwrite() result

On Mon, Aug 30, 2010 at 9:59 AM, Jim Meyering wrote: > Bruce Korb wrote: >> Hi Jim, >> >> On Mon, Aug 30, 2010 at 9:26 AM, Jim Meyering wrote: >>> I don't like the length of "ignore_value" either, but think of that >>> as a feature, not a problem.  It's more of an auto-regulator: If I'm >>> ignor

Re: failure to build due to ignoring fwrite() result

Hi Jim, On Mon, Aug 30, 2010 at 9:26 AM, Jim Meyering wrote: > I don't like the length of "ignore_value" either, but think of that > as a feature, not a problem.  It's more of an auto-regulator: If I'm > ignoring so many "important" return values that the "ignore_value" > uses impair readability,

Re: failure to build due to ignoring fwrite() result

Bruce Korb wrote: > Hi Eric, > On Mon, Aug 30, 2010 at 8:27 AM, Eric Blake wrote: >>>    (void)fwrite(...) >> >> Gnulib has the ignore-value module for places where casting to void is >> insufficient to shut up gcc. > > Many things are done in the interest of saving a few keystrokes. > In this cas

Re: failure to build due to ignoring fwrite() result

Bruce Korb wrote: > Hi Jim, > > On Mon, Aug 30, 2010 at 9:26 AM, Jim Meyering wrote: >> I don't like the length of "ignore_value" either, but think of that >> as a feature, not a problem.  It's more of an auto-regulator: If I'm >> ignoring so many "important" return values that the "ignore_value"

Re: failure to build due to ignoring fwrite() result

Hi Eric, On Mon, Aug 30, 2010 at 8:27 AM, Eric Blake wrote: >>    (void)fwrite(...) > > Gnulib has the ignore-value module for places where casting to void is > insufficient to shut up gcc. Many things are done in the interest of saving a few keystrokes. In this case, this: ignore_value(fwrit

Re: failure to build due to ignoring fwrite() result

On 08/30/2010 08:29 AM, Bruce Korb wrote: Every now and then, I'm thumped on the head by something fairly silly. This warning is quite silly: (void)fwrite(...) Gnulib has the ignore-value module for places where casting to void is insufficient to shut up gcc. Therefore, I suggest two f

Re: failure to build due to ignoring fwrite() result

Every now and then, I'm thumped on the head by something fairly silly. This warning is quite silly: (void)fwrite(...) On Sun, Aug 29, 2010 at 11:19 PM, wrote: > They're useless errors, all right.  I got colorgcc working again and had a > closer look.  There's a huge, long thread about this g