GNU bug report logs - #17072
dfa change apparently needed on Irix

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17072 in the body.
You can then email your comments to 17072 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Aharon Robbins <arnold <at> skeeve.com>
To: bug-grep <at> gnu.org
Subject: dfa change apparently needed on Irix
Date: Sun, 23 Mar 2014 21:32:21 +0200

FYI

Arnold
-------------------
> Date: Tue, 18 Mar 2014 13:44:57 -0600 (MDT)
> From: "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
> To: "Arnold Robbins" <arnold <at> skeeve.com>
> Cc: beebe <at> math.utah.edu
> Subject: gawk-4.1.0f: a patch for a failed build
>
> On SGI IRIX MIPS, gawk-4.1.0a had built and installed without problems
> on 13-Dec-2013.  
>
> For gawk-4.1.0f, however, I had to make one source code patch:
>
> % diff -c dfa.c.org dfa.c
> *** dfa.c.org   Mon Mar 10 14:39:05 2014
> --- dfa.c       Mon Mar 17 18:04:46 2014
> ***************
> *** 43,49 ****
>   #include "missing_d/gawkbool.h"
>   #endif /* HAVE_STDBOOL_H */
>   
> - #include "dfa.h"
>   
>   /* Gawk doesn't use Gnulib, so don't assume static_assert is present.  */
>   #ifndef static_assert
> --- 43,48 ----
> ***************
> *** 89,94 ****
> --- 88,95 ----
>   
>   #include "xalloc.h"
>   
> + #include "dfa.h"
> + 
>   #ifdef GAWK
>   static int
>   is_blank (int c)
>
> The reason for the patch is this error:
>
> 	dfa.c:956: error: conflicting types for 'case_folded_counterparts'
> 	dfa.h:111: error: previous declaration of 'case_folded_counterparts' was here
> 	dfa.c:956: error: conflicting types for 'case_folded_counterparts'
>
> What happens is that the prototype for that function has wchar_t
> arguments, but between the time that prototype is seen, and the first
> reference to the function is seen, wchar_t has been changed to char.
> Moving the inclusion of "dfa.h" later in "dfa.c" solved the problem.
>
> I configured and built like this:
>
> env CC='gcc -std=c99' CFLAGS=-D_SGI_SOURCE LDFLAGS='-L/usr/local/lib -Wl,-rpath,/usr/local/lib' ./configure && $B/make all check

Message #8 received at 17072 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Aharon Robbins <arnold <at> skeeve.com>, 17072 <at> debbugs.gnu.org
Subject: Re: bug#17072: dfa change apparently needed on Irix
Date: Sun, 23 Mar 2014 13:55:12 -0700

Aharon Robbins wrote:
> wchar_t has been changed to char

What changes wchar_t to char, and why?

I worry that if we just install this change, then some parts of grep 
and/or awk will be compiled with one wchar_t and others with a different 
one, which will lead to subtle problems at runtime on some platforms. 
That is, we'll turn a compile-time problem into a run-time one, which is 
a step backwards.

Instead, it's better to fix dfa.h so that it works regardless of what 
order files are included, but to do that we need to know what the actual 
problem is.

Message #17 received at 17072-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 17072-done <at> debbugs.gnu.org
Cc: 17157 <at> debbugs.gnu.org, bug-gawk <at> gnu.org,
 "Nelson H. F. Beebe" <beebe <at> math.utah.edu>
Subject: Re: bug#17072: dfa change apparently needed on Irix
Date: Sun, 06 Apr 2014 11:00:58 -0700

[Message part 1 (text/plain, inline)]

Thanks to Nelson H.F. Beebe's machines I've reproduced Bug#17072 on IRIX 
and have verified that the attached gawk patch fixes it.  This patch is 
almost identical to the gawk patch I submitted in 
<http://bugs.gnu.org/17157#44>.  It improves on the earlier patch only 
by changing gawk's dfa.c to look more like grep's dfa.c in one more way: 
include "dfa.h" before all other include files (except config.h).

I'll CC: this to Bug#17157 so that the patch is visible there too.  No 
further change should be needed to grep for this.

[0001-awk-simplify-dfa.c-by-having-it-not-include-mbsuppor.patch (text/plain, attachment)]

Message #20 received at 17072 <at> debbugs.gnu.org (full text, mbox):

From: arnold <at> skeeve.com
To: 17072 <at> debbugs.gnu.org
Subject: Re: bug#17072: closed (Re: bug#17072: dfa change apparently needed on
 Irix)
Date: Sun, 06 Apr 2014 14:27:14 -0600

Hello Paul.

> Your bug report
>
> #17072: dfa change apparently needed on Irix
>
> which was filed against the grep package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 17072 <at> debbugs.gnu.org.

Moving dfa.h back to where it was is likely to break OpenVMS. See
this in the gawk ChangeLog:

2013-01-31         Arnold D. Robbins     <arnold <at> skeeve.com>

	* dfa.c: Include "dfa.h" which includes regex.h after limits.h
	so that RE_DUP_MAX gets the correct value. Especially needed on
	OpenVMS. Thanks to Anders Wallin.

In general, I don't do stuff like that without a reason, and the reason
can usually be found in the ChangeLogs if you look (or check with me).

I would prefer to have dfa.h after the standard includes in dfa.c.
The current code works on Irix and other systems as is...

Thanks though.

Arnold

Message #23 received at 17072 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: arnold <at> skeeve.com, 17072 <at> debbugs.gnu.org
Cc: 17157 <at> debbugs.gnu.org
Subject: Re: bug#17072: closed (Re: bug#17072: dfa change apparently needed
 on Irix)
Date: Sun, 06 Apr 2014 14:26:03 -0700

[Message part 1 (text/plain, inline)]

arnold <at> skeeve.com wrote:
> 2013-01-31         Arnold D. Robbins<arnold <at> skeeve.com>
>
> 	* dfa.c: Include "dfa.h" which includes regex.h after limits.h
> 	so that RE_DUP_MAX gets the correct value.

Sorry, I missed that one.  We ran into that problem in Gnulib in March 
2012 and I should have included the fix in the proposed Gawk patch. 
Revised Gawk patch attached.  This affects only regex.h (to make it like 
gnulib regex.h with respect to RE_DUP_MAX) and mbsupport.h (to add a 
#define).

[0001-awk-simplify-dfa.c-by-having-it-not-include-mbsuppor.patch (text/plain, attachment)]

Message #26 received at 17072 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Aharon Robbins <arnold <at> skeeve.com>, 17381 <at> debbugs.gnu.org
Cc: 17072 <at> debbugs.gnu.org, 17157 <at> debbugs.gnu.org
Subject: Re: bug#17381: _GL_ATTRIBUTE_PURE in dfa.h
Date: Thu, 01 May 2014 23:11:06 -0700

[Message part 1 (text/plain, inline)]

On 05/01/2014 11:29 AM, Aharon Robbins wrote:
> custom.h is for system customization to override things that Autoconf 
> can't figure out or gets wrong

OK, it's easy to have something else include mbsupport.h instead. 
config.h, say.  The attached patch does that.  It doesn't really matter 
what includes it, so long as it's done before dfa.c and dfa.h start 
using the multibyte functions.

> Requiring gnulib in that header makes it less attractive to other 
> projects that might want to use dfa as a black box. Are there such? I 
> don't know. (I thought I'd heard something about gettext using dfa but 
> I am unsure if that is true.)

gettext uses gnulib, so that's not an issue.

> Does the GL_PURE stuff have to be on every declaration? Or can it just 
> be on the body?

It should be on the declaration for external functions, so that the 
function's caller knows to optimize it.

> What does it even mean

It means the function has no effects except the return value and that 
the return value depends only on the parameters and/or global variables.

> Does whatever optimization it enables *really* make a big difference, 
> or is it just a micro-optimization?

We put it in because GCC nowadays complains if we leave it out, if we 
configure with --enable-gcc-warnings.  The optimization seems to be a 
win in general and (more important) an aid for humans reading the code, 
so we typically just add the pure attribute and move on.

> Yes, I know. I am unsure if your patch, which totally eliminates the 
> ability to compile gawk on systems without multibyte support

It's not supposed to do that.  It's supposed to work on those hosts, by 
supplying substitutes for wchar_t, wctype_t, etc.  Hmm, are you worried 
about hosts that don't even have wchar.h and wctype.h?  If so, that can 
be worked around reasonably easily; please see attached patch.

> I just looked at the patch again. It really doesn't do the trick; 
> there are lots of places where MBS_SUPPORT is checked in the gawk code 
> and pulling mbsupport.h out of awk.h is likely to break things

No, it should still work.  With the revised patch, config.h includes 
mbsupport.h, so MBS_SUPPORT will be defined appropriately for gawk code 
and gawk's other MBS_SUPPORT usages will continue to work as before.

I'll CC: this to Bug#17157 and Bug#17072 as it's following up to the 
last messages in both those threads, too.

[0001-awk-simplify-dfa.c-by-having-it-not-include-mbsuppor.patch (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.