Re: [PATCH] Fix exit status of signal handlers in shell scripts

Bruno Haible wrote:

> Jim Meyering wrote:
>> Imagine that the first 10 tests pass, then each of the remaining ones is
>> killed via e.g., SIGHUP. ...
>> a naive search for "FAIL:" in the build output would find nothing.
>
> Yes, and it should be this way, IMO. Each time a user sees a "FAIL:", he
> should be encouraged to investigate.
>
> Whereas in the gettext test suite, often when I sent SIGINTs, I saw some
> tests fail without explanation. (This was due to a missing 'exit' statement
> in the trap handler, but it would be the same if there was an 'exit 1' in
> the trap handler.) I guessed that the FAIL report was due to the SIGINT and
> did not investigate. But I don't think this attitude should be encouraged.
>
> Similarly, when I get reports from Nelson Beebe with lots of failing tests,
> I don't want to spend time on fake failures that were due to, maybe, a
> shutdown of his virtual machine or something like this.
>
>> The final result would be highly misleading:
>>
>>     ========================
>>     All 10 tests passed
>>     (300 tests were not run)
>>     ========================
>
> But before this final result, you would see 300 times
>
>   Skipping test: caught fatal signal

avoid some warnings

In the process of preparing to release m4 1.4.14, I noticed several
warnings when compiling on Fedora Core 12.  I'm still working on silencing
the warning about gettimeofday having an incompatible second argument type
on glibc when using _GNU_SOURCE; I think the only sane solution is to
define GETTIMEOFDAY_TIMEZONE to either 'struct timezone' or 'void', and
recommend that application writers that need to use a function pointer use
the prototype:
int (*f) (struct timeval *, GETTIMEOFDAY_TIMEZONE *);

then updating the signature check in tests/test-gettimeofday.c
accordingly.  But in the meantime, here's what I'm pushing as prerequisite
to fixing gettimeofday:

--

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net

From 3220d5c6210870672d55ab27482fcdd1e964d75d Mon Sep 17 00:00:00 2001
From: Eric Blake <ebb9 <at> byu.net>
Date: Sat, 30 Jan 2010 07:37:11 -0700
Subject: [PATCH 1/3] tests: silence warning about system return

Silence a compiler warning for platforms that mark system()
with attribute warn_unused_result.

* tests/test-areadlink-with-size.c (main): Ignore system result.
* tests/test-areadlink.c (main): Likewise.
* tests/test-areadlinkat-with-size.c (main): Likewise.

Re: avoid some warnings

Eric Blake wrote:
> In the process of preparing to release m4 1.4.14, I noticed several
> warnings when compiling on Fedora Core 12.  I'm still working on silencing
> the warning about gettimeofday having an incompatible second argument type
> on glibc when using _GNU_SOURCE; I think the only sane solution is to
> define GETTIMEOFDAY_TIMEZONE to either 'struct timezone' or 'void', and
> recommend that application writers that need to use a function pointer use
> the prototype:
> int (*f) (struct timeval *, GETTIMEOFDAY_TIMEZONE *);

Sounds reasonable.

> then updating the signature check in tests/test-gettimeofday.c
> accordingly.  But in the meantime, here's what I'm pushing as prerequisite
> to fixing gettimeofday:
>
...
> Subject: [PATCH 1/3] tests: silence warning about system return
>
> Silence a compiler warning for platforms that mark system()
> with attribute warn_unused_result.
>
> * tests/test-areadlink-with-size.c (main): Ignore system result.
> * tests/test-areadlink.c (main): Likewise.
> * tests/test-areadlinkat-with-size.c (main): Likewise.
> * tests/test-areadlinkat.c (main): Likewise.
> * tests/test-canonicalize-lgpl.c (main): Likewise.
> * tests/test-canonicalize.c (main): Likewise.
> * tests/test-chown.c (main): Likewise.
...

Re: avoid some warnings

According to Jim Meyering on 2/1/2010 6:56 AM:
>> int (*f) (struct timeval *, GETTIMEOFDAY_TIMEZONE *);
> 
> Sounds reasonable.

By the way, I haven't forgotten that forkpty and openpty also need help to
avoid signature check warnings:
http://lists.gnu.org/archive/html/bug-gnulib/2009-12/msg00312.html

--

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net

[PATCH] removing useless parentheses in cpp #define directives

FYI, continuing the clean-up, I ran this:

  git grep -E 'define.*\(\([^)]+\),'

and fixed some of the culprits in the patch below.
The following remain (from glibc), and I'll leave them as-is:

    lib/regex_internal.h:#  define internal_function   __attribute ((regparm (3), stdcall))
    lib/strsignal.c:# define __libc_once(NAME, INIT) gl_once ((NAME), (INIT))
    lib/strsignal.c:# define __libc_setspecific(NAME, POINTER) gl_tls_set ((NAME), (POINTER))
    lib/strtol.c:#  define ISSPACE(Ch) __iswspace_l ((Ch), loc)
    lib/strtol.c:#  define ISALPHA(Ch) __iswalpha_l ((Ch), loc)
    lib/strtol.c:#  define TOUPPER(Ch) __towupper_l ((Ch), loc)
    lib/strtol.c:#  define ISSPACE(Ch) __isspace_l ((Ch), loc)
    lib/strtol.c:#  define ISALPHA(Ch) __isalpha_l ((Ch), loc)
    lib/strtol.c:#  define TOUPPER(Ch) __toupper_l ((Ch), loc)

From 67e58686c25ce341565a000d91073920488f618f Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Mon, 1 Feb 2010 19:05:26 +0100
Subject: [PATCH] removing useless parentheses in cpp #define directives

For motivation, see commit c0221df4, "define STREQ(a,b)
consistently, removing useless parentheses"
* lib/memcmp.c (CMP_LT_OR_GT): Remove useless parentheses.
* lib/mountlist.c (MNT_IGNORE): Likewise.
* lib/trim.h (trim, trim_trailing, trim_leading): Likewise.
---
 ChangeLog       |    9 +++++++++
 lib/memcmp.c    |    2 +-

Re: maintainer-makefile troubles and suggestions

On 31.01.2010 19:11, Bruno Haible wrote:
> There is the possibility to use approach 3, by
>   - using the gnulib-tool options --po-base and --po-domain,
>   - defining the DEFAULT_TEXT_DOMAIN macro in lib/Makefile.am.
> The PO files for gnulib will be automatically downloaded from the Translation
> Project's website <http://translationproject.org/domain/gnulib.html>. This
> approach should certainly be better documented and more used.

Thank you, Bruno, that is indeed a good solution. Saved my translators
30 strings.

With that configuration in place I only had to remove the gnulib dirs
from the sc_po_check check in maint.mk.

I guess I could write a patch to detect use of po-base, and auto-adjust
the check accordingly. However, as my gnulib assignment form hasn't even
arrived here yet, I'm reluctant to write more patches that cannot be
legally included yet. So if someone who's already done the paperwork
wants to have a look, I'd be glad.

Martin

[PATCH] ensure that the regexp [b-a] is diagnosed as invalid

I've just pushed the following patch.
It's needed by grep, to accommodate changes I'm about to push there.

It adds a test to gl_REGEX that ensures that re_compiler_pattern
diagnoses [b-a] as invalid when using RE_SYNTAX_POSIX_EGREP.
The net result is no change on x86_64, since on such systems,
the included regex code was already required due to a later test.
However, on [3-6]86-based systems, this macro used to allow
the containing application to use a glibc-provided regex, but with
this change, it will always require the gnulib-supplied one.

I'll file a glibc bug shortly.

From 18f8ae4bbed4d919e564fe54b94feb6bce2c4c8f Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Tue, 19 Jan 2010 08:25:12 +0100
Subject: [PATCH] ensure that the regexp [b-a] is diagnosed as invalid

* m4/regex.m4 (gl_REGEX): Ensure that re_compiler_pattern
diagnoses [b-a] as invalid when using RE_SYNTAX_POSIX_EGREP.
Currently, glibc-2.11.90-10 fails to do that.
---
 m4/regex.m4 |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/m4/regex.m4 b/m4/regex.m4
index a702252..6bd6b8f 100644
--- a/m4/regex.m4
+++ b/m4/regex.m4
 <at>  <at>  -94,10 +94,17  <at>  <at>  AC_DEFUN([gl_REGEX],

Re: [PATCH] ensure that the regexp [b-a] is diagnosed as invalid

Jim Meyering <jim <at> meyering.net> writes:

> It adds a test to gl_REGEX that ensures that re_compiler_pattern
> diagnoses [b-a] as invalid when using RE_SYNTAX_POSIX_EGREP.

Where does POSIX state that this is invalid?  So far, I can only see that it is 
undefined, but have not found any hard requirements that it be a failure.

http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html

9.3.5 RE Bracket Expression, step 7: "The starting range point and the ending 
range point shall be a collating element or collating symbol.... If the 
represented set of collating elements is empty, it is unspecified whether the 
expression matches nothing, or is treated as invalid."

That said, forcing a hard failure is probably the best QoI implementation of 
undefined behavior.

--

-- 
Eric Blake

Re: [PATCH] ensure that the regexp [b-a] is diagnosed as invalid

Eric Blake wrote:
> Jim Meyering <jim <at> meyering.net> writes:
>> It adds a test to gl_REGEX that ensures that re_compiler_pattern
>> diagnoses [b-a] as invalid when using RE_SYNTAX_POSIX_EGREP.
>
> Where does POSIX state that this is invalid?

Thanks for looking.

I too verified (before embarking) that POSIX does not declare it invalid,
merely unspecified. However, since gnulib's regex has rejected such
ranges for a long time and sed, awk, perl, etc. act that way, I think
it's the way to go.

Note also that glibc's code appears to try to implement the same
behavior (though conditional upon RE_NO_EMPTY_RANGES, which nearly
everyone uses), but somehow that code does not function properly:

      start_collseq = lookup_collation_sequence_value (start_elem);
      end_collseq = lookup_collation_sequence_value (end_elem);
      /* Check start/end collation sequence values.  */
      if (BE (start_collseq == UINT_MAX || end_collseq == UINT_MAX, 0))
	return REG_ECOLLATE;
      if (BE ((syntax & RE_NO_EMPTY_RANGES) && start_collseq > end_collseq, 0))
	return REG_ERANGE;

I've just filed this glibc bug:

    http://sourceware.org/bugzilla/show_bug.cgi?id=11244

[PATCH] regcomp.c: avoid the sole warning from gcc's -Wtype-limits

This may be the final piece I require to allow grep to use gnulib's
regex module:

From 9d0ad652de159d08e5f679842f8a2a5658196361 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering <at> redhat.com>
Date: Wed, 3 Feb 2010 18:01:36 +0100
Subject: [PATCH] regcomp.c: avoid the sole warning from gcc's -Wtype-limits

* lib/regcomp.c (TYPE_SIGNED): Define.
(parse_dup_op): Use it to avoid the sole warning from -Wtype-limits.
---
 ChangeLog     |    4 ++++
 lib/regcomp.c |    6 +++++-
 2 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index fb38064..093bdcf 100644
--- a/ChangeLog
+++ b/ChangeLog
 <at>  <at>  -1,5 +1,9  <at>  <at> 
 2010-02-03  Jim Meyering  <meyering <at> redhat.com>

+	regcomp.c: avoid the sole warning from gcc's -Wtype-limits
+	* lib/regcomp.c (TYPE_SIGNED): Define.
+	(parse_dup_op): Use it to avoid the sole warning from -Wtype-limits.
+
 	regcomp.c: avoid a new -Wshadow warning
 	* lib/regcomp.c (create_initial_state): Do not shadow local "err".

diff --git a/lib/regcomp.c b/lib/regcomp.c