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, bugzilla-dae...@gentoo.org wrote:
They're useless errors, all right. I got colorgcc working again and had a
closer look. There's a huge,
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
Hi Eric,
On Mon, Aug 30, 2010 at 8:27 AM, Eric Blake ebl...@redhat.com 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:
Bruce Korb wrote:
Hi Jim,
On Mon, Aug 30, 2010 at 9:26 AM, Jim Meyering j...@meyering.net 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
Hi Jim,
On Mon, Aug 30, 2010 at 9:26 AM, Jim Meyering j...@meyering.net 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
On Mon, Aug 30, 2010 at 9:59 AM, Jim Meyering j...@meyering.net wrote:
Bruce Korb wrote:
Hi Jim,
On Mon, Aug 30, 2010 at 9:26 AM, Jim Meyering j...@meyering.net 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
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
insufficient to
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 use
Hi Bruno,
On 8/28/10, Bruno Haible br...@clisp.org 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?
[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
Bruce Korb wrote:
On Mon, Aug 30, 2010 at 9:59 AM, Jim Meyering j...@meyering.net wrote:
Bruce Korb wrote:
Hi Jim,
On Mon, Aug 30, 2010 at 9:26 AM, Jim Meyering j...@meyering.net wrote:
I don't like the length of ignore_value either, but think of that
as a feature, not a problem. It's more
Howdy, another penny or two:
On Mon, Aug 30, 2010 at 12:52 PM, Jim Meyering j...@meyering.net 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
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 casting to void is
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/
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
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
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
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
* 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
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
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
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 whether
On Mon, Aug 30, 2010 at 1:57 PM, Jim Meyering j...@meyering.net 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.
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 say, *printf.
* tests/test-malloca.c (do_allocation): Avoid dead store.
Signed-off-by: Eric Blake ebl...@redhat.com
---
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
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
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
* lib/hash.c (hash_get_next): Aid clang analysis.
Signed-off-by: Eric Blake ebl...@redhat.com
---
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
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'.
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
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
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 ugly to
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) {
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(), but
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
* 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 ebl...@redhat.com
---
ChangeLog|8
m4/memmem.m4 |5 +++--
m4/strcasestr.m4
(adding bug-standa...@gnu.org 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
http://lists.gnu.org/archive/html/bug-gnulib/2010-08/msg00233.html.
This doesn't capture all the comments there
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
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
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 also generate
40 matches
Mail list logo
