Re: [pcre-dev] Problems and questions about locales

Hello Philip,

Sorry to reply so late, I was busy last week... some urgent developments
to do.
Yes, it should be useful but consider the following idea, at no cost :
To be consistent with the pcre2_maketables_free() function in terms of
alloc/free usage,
provide a pcre2_maketables_reserve() function :

PCRE2_EXP_DEFN uint8_t * PCRE2_CALL_CONVENTION
pcre2_maketables_reserve(pcre2_general_context *gcontext, PCRE2_SIZE
*table_size )

which do the allocation, the same as at the beginning of
pcre2_maketables() and can be reused here
and return the table buffer and tables_length in table_size parameter.

In dftables, add a -b option to save the table buffer after computation
in binary format instead of the C format ;
the file argument is unchanged.

For your information, I woke up my very old Atari 1040 STF (Motorola 68K
family) so a real Big Endian computer.
A little bit complicated but feasible, playing with 3.5" floppy to get
sources, reinstall K&R C compiler on 30MB Hard disk drive...
Found a bug in th fread function that eats two bytes (so I use read) and
found no difference in binary to clear text process
between the Atari and my PC.

Kind regards,
Patrice.

ph10@??? a écrit :
> On Mon, 17 Feb 2020, I wrote:
>
>> On Fri, 14 Feb 2020, Patrice Guérin wrote:
>>
>>> At my opinion, pcre2_maketables() is independant of 8/16/32 bits since it's
>>> defined as uint8_t (ie bytes).
>>> For the same reason, I think there is no endianness issue in the computation
>>> of the table.
>>> Saving and loading in binary should be ok.
>> I have put this on a list to think about.
> It has occurred to me that all you need is the length of the tables (in
> bytes) and then you can save/restore them yourself. I could most easily
> do this by adding a new option to pcre2_config(). [It's not really a
> configuration value, but that saves having to invent a whole new
> function.] Does this seem reasonable/useful?
>
> Philip
>