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

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

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

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

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

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

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

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

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: feature request: detect CPU instruction set

Hi Bruno, On 8/28/10, Bruno Haible wrote: > Sam, you contributed a significant part to the > FFCALL_CANONICAL_HOST_CPU code that you proposed, from which this one here > is derived. Would you mind starting the paperwork process for assigning > your gnulib contributions to the FSF? Please refe

Re: next m4 snapshot [was: debugging M4 on AIX 5.3]

[phooey - hit send too soon] On 08/30/2010 01:53 PM, Eric Blake wrote: On 08/21/2010 02:42 AM, Ralf Wildenhues wrote: I'm trying to debug the recent regression of git branch-1.4 M4 over M4 1.4.14 on AIX. Here's the latest snapshot tarball, if nothing goes terribly wrong, then I hope to get 1.

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

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

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

next m4 snapshot [was: debugging M4 on AIX 5.3]

On 08/21/2010 02:42 AM, Ralf Wildenhues wrote: I'm trying to debug the recent regression of git branch-1.4 M4 over M4 1.4.14 on AIX. Here's the latest snapshot tarball, if nothing goes terribly wrong, then I hope to get 1.4.15 out the door this week. http://people.redhat.com/eblake/m4/ http:

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

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 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 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

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/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: next m4 snapshot

* Eric Blake wrote on Mon, Aug 30, 2010 at 09:55:02PM CEST: > >Here's the latest snapshot tarball, if nothing goes terribly wrong, then > >I hope to get 1.4.15 out the door this week. > http://people.redhat.com/eblake/m4/m4-1.4.14.9-edf2d.tar.gz Passes check on AIX 5.3. Cheers, Ralf

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/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

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 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

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

[PATCH] tests: silence clang warning

* tests/test-malloca.c (do_allocation): Avoid dead store. Signed-off-by: Eric Blake --- I ran clang on m4, and found a couple of warnings. It warned about this as a dead store, and it's easy enough to avoid. Clang also warned about some potential null dereferences in gl_avltree_oset.c; but I t

Re: feature request: detect CPU instruction set

Hi Sam, > PS. I do not see the new module under git. It is not yet committed, because I'm waiting for comments and reviews from you and others. > I think I have already contributed and thus you should already have > all the papers. I'm following up to this in private mail. Bruno

enhancements valgrind-tests.m4

Hello, I made some enhancements to the valgrind-tests.m4 file which I find quite handy and wanted to put tem into discussion. The main changes are: Memory leaks can be treated as errors (--enable-valgrind-memleaks-are-errors) Possibility for overriding the default arguments for valgrind via V

[PATCH] hash: silence spurious clang warning

* lib/hash.c (hash_get_next): Aid clang analysis. Signed-off-by: Eric Blake --- Jim, should we apply this? As far as I can tell, this is an example of a shortfall in clang 2.7, as shipped in Fedora 13. Clang assumed that the for loop at line 310 is skipped because cursor is NULL, which implies

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

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

bogus configure output for strstr

I noticed this when testing m4 on FreeBSD: checking whether strstr works in linear time... Alarm clock no That's because conftest ends via a signal in this case, and some shells, including FreeBSD's /bin/sh, are rather verbose about processes that died because of a signal rather than a normal

Re: [PATCH] tests: silence clang warning

Hi Eric, > I ran clang on m4, and found a couple of warnings. It warned > about this as a dead store, and it's easy enough to avoid. I would not put so as much pressure to get excellent, warning-free code on the tests/ than on lib/. Your efforts are worthy for lib/*.c. But if there is a hidden s

Re: [PATCH] hash: silence spurious clang warning

Hi Eric, > - if (! (bucket < table->bucket_limit)) > + if (! (bucket && bucket < table->bucket_limit)) > abort (); I would not apply this, because it causes a slowdown at runtime for no good reason. I think the paragraph that Paul cited just three hours ago "Don't make the program ugl

Re: bogus configure output for strstr

Hi Eric, > Is it worth trying to silence the spurious "Alarm clock" message Yes: The normal configure output should be as regular as possible, because we want users to report anomalies to us. > by changing strstr.m4 (and friends with related timeout idioms) to use: > > static void quit (int sig

Re: [PATCH] hash: silence spurious clang warning

On 08/30/2010 05:09 PM, Bruno Haible wrote: Hi Eric, - if (! (bucket< table->bucket_limit)) + if (! (bucket&& bucket< table->bucket_limit)) abort (); I would not apply this, because it causes a slowdown at runtime for no good reason. Hmm - I see the point of the original abort(),

Re: bogus configure output for strstr

On 08/30/2010 05:20 PM, Bruno Haible wrote: static void quit (int sig) { exit (sig + 128); } ... signal (SIGALRM, quit); I tested this on FreeBSD, and it indeed works. And given that sleep.m4 already installs a handler, it's no less portable than what we are already doing in other test

[PATCH] strstr, memmem, strcasestr: avoid leaked shell message

* m4/strstr.m4 (gl_FUNC_STRSTR): Avoid "Alarm clock" message from FreeBSD. * m4/strcasestr.m4 (gl_FUNC_STRCASESTR): Likewise. * m4/memmem.m4 (gl_FUNC_MEMMEM): Likewise. Signed-off-by: Eric Blake --- ChangeLog|8 m4/memmem.m4 |5 +++-- m4/strcasestr.m4 |5 +++-- m

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

New stable snapshot

Hi, I've released a new stable snapshot. See attached NEWS.stable for details. Tarball: http://erislabs.net/ianb/projects/gnulib/gnulib-20100829-stable.tar.gz Gitweb: http://erislabs.net/gitweb?p=gnulib.git;a=shortlog;h=refs/heads/stable Git: git://erislabs.net/gnulib.git tag: stable/20100829

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

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: next m4 snapshot

Hello, On 30.08.2010 22:31, Ralf Wildenhues wrote: > * Eric Blake wrote on Mon, Aug 30, 2010 at 09:55:02PM CEST: >>> Here's the latest snapshot tarball, if nothing goes terribly wrong, then >>> I hope to get 1.4.15 out the door this week. >> http://people.redhat.com/eblake/m4/m4-1.4.14.9-edf2d.ta

Re: [PATCH] hash: silence spurious clang warning

Bruno Haible wrote: > Hi Eric, > >> - if (! (bucket < table->bucket_limit)) >> + if (! (bucket && bucket < table->bucket_limit)) >> abort (); > > I would not apply this, because it causes a slowdown at runtime > for no good reason. > > I think the paragraph that Paul cited just three hours