[coreutils] [PATCH] sort: avoid gcc warning: explicitly ignore strtold result
I've just tried to build coreutils and got this:
cc1: warnings being treated as errors
sort.c: In function 'debug_key':
sort.c:2207: error: ignoring return value of 'strtold', declared with
attribute warn_unused_result
Here's the fix:
From ec0d6ddb813e95a01421b45f1743713e88175448 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 10 Aug 2010 08:11:15 -0700
Subject: [PATCH] sort: avoid gcc warning: explicitly ignore strtold result
* src/sort.c: Include ignore-value.h.
(debug_key): Use ignore_value.
---
src/sort.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/sort.c b/src/sort.c
index 148ed3e..084f4e3 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -35,6 +35,7 @@
#include hard-locale.h
#include hash.h
#include heap.h
+#include ignore-value.h
#include md5.h
#include mbswidth.h
#include nproc.h
@@ -2204,7 +2205,7 @@ debug_key (struct line const *line, struct keyfield const
*key)
if (key-month)
getmonth (beg, tighter_lim);
else if (key-general_numeric)
-strtold (beg, tighter_lim);
+ignore_value (strtold (beg, tighter_lim));
else if (key-numeric || key-human_numeric)
{
char *p = beg + (beg lim *beg == '-');
--
1.7.2
bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)
On 08/09/10 09:25, Bruno Haible wrote:
The contents of the 'allocated' buffer is scratch, therefore malloc + free
should be faster than realloc...
Also, the '3 * (lena + lenb)' guess is pessimistic; it is possible that
it may return with ENOMEM when in fact strxfrm's real needs would not
lead to ENOMEM.
Thanks again; I installed this:
* src/sort.c (compare_random): Use free/xmalloc rather than
xrealloc, since the old buffer contents need not be preserved.
Also, don't fail if the guessed-sized malloc fails. Suggested by
Bruno Haible.
---
src/sort.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/sort.c b/src/sort.c
index 084f4e3..3dc7ae0 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -2056,7 +2056,13 @@ compare_random (char *restrict texta, size_t lena,
if (bufsize guess_bufsize)
{
bufsize = MAX (guess_bufsize, bufsize * 3 / 2);
- buf = allocated = xrealloc (allocated, bufsize);
+ free (allocated);
+ buf = allocated = malloc (bufsize);
+ if (! buf)
+{
+ buf = stackbuf;
+ bufsize = sizeof stackbuf;
+}
}
size_t sizea =
@@ -2074,7 +2080,8 @@ compare_random (char *restrict texta, size_t lena,
bufsize = sizea + sizeb;
if (bufsize SIZE_MAX / 3)
bufsize = bufsize * 3 / 2;
- buf = allocated = xrealloc (allocated, bufsize);
+ free (allocated);
+ buf = allocated = xmalloc (bufsize);
if (texta lima)
strxfrm (buf, texta, sizea);
if (textb limb)
--
1.7.2
bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)
Hi Paul, All I'm saying is that the gnulib variant shouldn't use a name starting with mem, because the mem* names have similar properties and the gnulib variant departs dramatically from these properties. The strdup/strndup functions are cases in point. Their names were controversial, and they had quite some trouble getting into POSIX, precisely because their names began with str but (unlike the other str* functions) they allocated memory. But now they are in POSIX. So, precedent is existing. On the other hand, it has now appeared that strxfrm would be easier to use efficiently if it had a wrapper that incorporated the allocate 3 * len bytes before calling strxfrm heuristic. If we add such a wrapper to gnulib, it could be called 'astrxfrm' extern char * astrxfrm (const char *s, char *resultbuf, size_t *lengthp); and then I would agree to renaming memxfrm - amemxfrm, for consistency. Bruno
bug#6789: propose renaming gnulib memxfrm to amemxfrm (naming collision with coreutils)
On 08/11/10 02:38, Bruno Haible wrote: extern char * astrxfrm (const char *s, char *resultbuf, size_t *lengthp); Yes, that looks like a useful addition. Thanks for the suggestion.
