FYI: dfa: add an assertion to avoid coverity false positive

2016-12-13 Thread Jim Meyering 
It took me a few minutes to convince myself that a coverity warning
was unwarranted, so I've added an assert that should suppress it.

If someone sees a better way (i.e., with no assertion), please suggest a patch.
From 744c745300fa7b1c73dd9f6b323d3bf4823857e6 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Mon, 12 Dec 2016 21:12:14 -0800
Subject: [PATCH] dfa: add an assertion to avoid coverity false positive

* lib/dfa.c (realloc_trans_if_necessary): Otherwise, coverity
warned that "newalloc1 - 2" could overflow.
---
 ChangeLog | 6 ++
 lib/dfa.c | 1 +
 2 files changed, 7 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 8f1671a..69be242 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2016-12-12  Jim Meyering  
+
+   dfa: add an assertion to avoid coverity false positive
+   * lib/dfa.c (realloc_trans_if_necessary): Otherwise, coverity
+   warned that "newalloc1 - 2" could overflow.
+
 2016-12-13   Arnold D. Robbins  

dfa: remove DFA_CASE_FOLD flag in favor of RE_ICASE
diff --git a/lib/dfa.c b/lib/dfa.c
index 6fee7a1..c29dd02 100644
--- a/lib/dfa.c
+++ b/lib/dfa.c
@@ -2778,6 +2778,7 @@ realloc_trans_if_necessary (struct dfa *d, state_num 
new_state)
   realtrans = x2nrealloc (realtrans, &newalloc1, sizeof *realtrans);
   realtrans[0] = realtrans[1] = NULL;
   d->trans = realtrans + 2;
+  assert (2 <= newalloc1);
   d->tralloc = newalloc = newalloc1 - 2;
   d->fails = xnrealloc (d->fails, newalloc, sizeof *d->fails);
   d->success = xnrealloc (d->success, newalloc, sizeof *d->success);
-- 
2.9.3

Re: [Grep-devel] patches for removing DFA_CASE_FOLD

2016-12-13 Thread arnold 
Paul Eggert  wrote:

> On 12/13/2016 12:26 PM, Arnold Robbins wrote:
> > -  dfa->syntax.case_fold = (dfaopts & DFA_CASE_FOLD) != 0;
> > +  dfa->syntax.case_fold = (bits & RE_ICASE) != 0
>
> I'm afraid that didn't work, due to a missing semicolon. I fixed that 
> up, fiddled with the commit messages, updated grep submodules, and 
> installed the result into gnulib and grep.

Wonderful, thanks!

Arnold

Re: [Grep-devel] patches for removing DFA_CASE_FOLD

2016-12-13 Thread Jim Meyering 
On Tue, Dec 13, 2016 at 2:51 PM, Paul Eggert  wrote:
> On 12/13/2016 12:26 PM, Arnold Robbins wrote:
>>
>> -  dfa->syntax.case_fold = (dfaopts & DFA_CASE_FOLD) != 0;
>> +  dfa->syntax.case_fold = (bits & RE_ICASE) != 0
>
>
> I'm afraid that didn't work, due to a missing semicolon. I fixed that up,
> fiddled with the commit messages, updated grep submodules, and installed the
> result into gnulib and grep.

Thank you both.

Re: [Grep-devel] patches for removing DFA_CASE_FOLD

2016-12-13 Thread Paul Eggert 

On 12/13/2016 12:26 PM, Arnold Robbins wrote:

-  dfa->syntax.case_fold = (dfaopts & DFA_CASE_FOLD) != 0;
+  dfa->syntax.case_fold = (bits & RE_ICASE) != 0


I'm afraid that didn't work, due to a missing semicolon. I fixed that 
up, fiddled with the commit messages, updated grep submodules, and 
installed the result into gnulib and grep.

Re: Small change needed for link.m4

2016-12-13 Thread Pádraig Brady 
On 13/12/16 17:43, John W. Eaton wrote:
> The test in link.m4 needs to include  to provide a declaration 
> for the rename function.  The test fails if building with GCC's 
> -Werror=implicit-function-declaration option.
> 
> This was reported as part of a bug with building Octave on Fedora, which 
> now uses -Werror=implicit-function-declaration by default.
> 
> https://savannah.gnu.org/bugs/?49782
> 
> jwe
> 

pushed.

thanks!

Small change needed for link.m4

2016-12-13 Thread John W. Eaton 
The test in link.m4 needs to include  to provide a declaration 
for the rename function.  The test fails if building with GCC's 
-Werror=implicit-function-declaration option.


This was reported as part of a bug with building Octave on Fedora, which 
now uses -Werror=implicit-function-declaration by default.


https://savannah.gnu.org/bugs/?49782

jwe
diff -up octave-4.2.0/m4/link.m4.implicit octave-4.2.0/m4/link.m4
--- octave-4.2.0/m4/link.m4.implicit2016-11-13 08:21:54.0 -0700
+++ octave-4.2.0/m4/link.m4 2016-12-06 13:52:47.132003993 -0700
@@ -22,6 +22,7 @@ AC_DEFUN([gl_FUNC_LINK],
AC_RUN_IFELSE(
  [AC_LANG_PROGRAM(
[[#include 
+ #include 
]],
[[int result = 0;
  if (!link ("conftest.a", "conftest.b/"))

Re: MSVC and fseeko.c

2016-12-13 Thread Bruno Haible 
Gisle Vanem wrote:
> Bruno Haible wrote:
> 
> > $ ./gnulib-tool --create-testdir --dir=/tmp/testdir-stdioext --with-tests \
> > --single-configure --avoid=havelib-tests \
> > fseterr freadable fwritable fbufmode freading fwriting \
> > freadptr freadseek freadahead fpurge fseeko ftello fpending 
> > \
> > fflush
> > 
> > With this patch, this testdir passes its testsuite on MSVC 14, both in 
> > 32-bit
> > and in 64-bit mode, except for the 'fpending' module.
> 
> Thanks alot for your effort on this. It compiles fine, but I'm not sure
> it works for all test-f*.exe tests. In test-fseeko.exe, I get this assert:
>   test-fseeko.c:45: assertion 'r1 == r2 && r1 == expected' failed
> 
> (r1 = -1, r2 = 0, expected = 0).

And what about the other tests? When "make check" runs, which fail?
(This info should give a hint about where to start looking.)

> You tested this with MSVC 14?

Yes.

> Does this use the "old" MSVCRT.dll?

No, it uses vcruntime140.dll.

> BTW. I'm on Win-10 using MSVC 2015 and the WindowsKit (Universal CRT
> ver. 10.0.10586.0).

Mine is 10.0.10240.0.

> I noticed you patched stdio-impl.h with the 'struct _gl_real_FILE' stuff.
> Are you sure this is compatible with this newer Windows SDK?

No, Microsoft won't tell me when they make internal changes in their library.

Bruno

Re: MSVC and fseeko.c

2016-12-13 Thread Gisle Vanem 
Bruno Haible wrote:

> $ ./gnulib-tool --create-testdir --dir=/tmp/testdir-stdioext --with-tests \
> --single-configure --avoid=havelib-tests \
> fseterr freadable fwritable fbufmode freading fwriting \
> freadptr freadseek freadahead fpurge fseeko ftello fpending \
> fflush
> 
> With this patch, this testdir passes its testsuite on MSVC 14, both in 32-bit
> and in 64-bit mode, except for the 'fpending' module.

Thanks alot for your effort on this. It compiles fine, but I'm not sure
it works for all test-f*.exe tests. In test-fseeko.exe, I get this assert:
  test-fseeko.c:45: assertion 'r1 == r2 && r1 == expected' failed

(r1 = -1, r2 = 0, expected = 0).

You tested this with MSVC 14? Does this use the "old" MSVCRT.dll?
BTW. I'm on Win-10 using MSVC 2015 and the WindowsKit (Universal CRT
ver. 10.0.10586.0).

I noticed you patched stdio-impl.h with the 'struct _gl_real_FILE' stuff.
Are you sure this is compatible with this newer Windows SDK?

-- 
--gv

Re: MSVC and fpending

2016-12-13 Thread Bruno Haible 
Jim Meyering wrote:
> That sounds good, and your patch looks fine.
> Thanks for taking that on.

OK. Pushed.

Bruno
--
In memoriam the victims of the Massacre of Margarita Belén