[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dfa.c no longer usable if no 64-bit support
From: |
Paul Eggert |
Subject: |
Re: dfa.c no longer usable if no 64-bit support |
Date: |
Wed, 29 Jan 2020 11:16:37 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
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