Re: dfa.c no longer usable if no 64-bit support

[Paul Eggert]

On 1/29/20 7:34 AM, Bruno Haible wrote:
> I would say that it's not worth the effort - except for the person(s)
> who care a lot about Vax/VMS.

Normally I'd agree, but if Arnold cares about VAX/VMS and if we want 
Gnulib dfa.c to match Gawk dfa.c, then in this particular case it makes 
some sense to support 32-bit-only platforms, as it's easy to revert the 
recent patch that made dfa.c assume 64-bit. So I installed the attached.

However, I see some other parts of departure for Gawk dfa.c:

* Gawk dfa.c/dfa.h does not use flexible array members or the 
portable-to-7th-edition-Unix substitute provided by Gnulib, so I suggest 
that Gawk import Gnulib lib/flexmember.h, and either "#define 
FLEXIBLE_ARRAY_MEMBER 1" in config.h or (better) import Gnulib 
m4/flexmember.m4.

* Gawk dfa.c doesn't use isblank, but instead defines its own is_blank 
that is hard-coded to the C locale. Isn't [[:blank:]] supposed to be 
locale-dependent? Or are you assuming that space and tab are the only 
blank characters in all single-byte locales?

* Gawk dfa.c includes mbsupport.h if __DJGPP__ is defined. I suggest 
moving this to Gawk config.h so that dfa.c need not worry about it.

* Gawk dfa.c replaces "#include <stdint.h>" with:

#ifndef VMS
#include <stdint.h>
#else
#define SIZE_MAX __INT32_MAX
#define PTRDIFF_MAX __INT32_MAX
#endif

I suppose we could add something like this to Gnulib dfa.c but it's a 
bit ugly; is there a cleaner way to do it? Perhaps Gawk could supply its 
own little substitute stdint.h on VMS. (Gnulib does this too but I 
assume Gnulib's stdint.h is too heavyweight for Gawk.)

0001-dfa-do-not-assume-64-bit-int.patch
Description: Text Data