Re: gawk 3.1.1n problems reported by Sun WorkShop 6 update 2 C 5.3

[Aharon Robbins]

> Date: Mon, 10 Mar 2003 13:20:59 -0800 (PST)
> From: Paul Eggert <address@hidden>
> To: address@hidden
> Subject: gawk 3.1.1n problems reported by Sun WorkShop 6 update 2 C 5.3
>
> I built gawk 3.1.1n on Solaris 7 sparc with Sun WorkShop 6 update 2 C
> 5.3 in 64-bit mode (configured with "CFLAGS='cc -xarch=v9'
> configure"), and it reported the following diagnostics.
>
> cc -xarch=v9 -DDEFPATH="\".:/usr/local/share/awk\"" -DHAVE_CONFIG_H -DGAWK 
> -DLOCALEDIR="\"/usr/local/share/locale\"" -I. -I../gawk-3.1.1n -I. 
> -I../gawk-3.1.1n/intl    -g -c `test -f '../gawk-3.1.1n/io.c' || echo 
> '../gawk-3.1.1n/'`../gawk-3.1.1n/io.c
> "../gawk-3.1.1n/io.c", line 2895: warning: statement not reached
>
> cc -xarch=v9 -DDEFPATH="\".:/usr/local/share/awk\"" -DHAVE_CONFIG_H -DGAWK 
> -DLOCALEDIR="\"/usr/local/share/locale\"" -I. -I../gawk-3.1.1n -I. 
> -I../gawk-3.1.1n/intl    -g -c `test -f '../gawk-3.1.1n/regex.c' || echo 
> '../gawk-3.1.1n/'`../gawk-3.1.1n/regex.c
> "/usr/include/limits.h", line 175: warning: macro redefined: RE_DUP_MAX
> "../gawk-3.1.1n/regcomp.c", line 3358: warning: integer overflow detected: op 
> "<<"
>
> All the diagnostics seem to be relevant.
>
> First, io.c contains some unused (the <rsnull end loop logic>).  This
> is not a bug in and of itself, but it indicates that there might be a
> bug nearby.

I will revisit this code after the release.  Right now the current logic
works, and I'm desperately trying to freeze the code.

> Second, regex.c includes regex_internal.h, (which includes the system
> limits.h, which defines RE_DUP_MAX) before including <regex.h>,
> causing the RE_DUP_MAX problem.

Actually, it includes <regex.h> before limits.h, which is the problem.
I've rearranged the includes a bit, and things should be OK now.  Thanks.

> Third, regcomp.c computes 1 << 31, which has undefined behavior due to
> overflow; it should compute ((unsigned int) 1 << 31) instead.  This is
> not a bug on this particular platform, but I suppose it might be a bug
> on other platforms.

I've changed all `1 << xxx' to be `1UL << xxx' which should do the trick;
that's less messy than a cast and should work even on a 16-bit system.

Thanks,

Arnold