Author: Patrice Guérin Date: To: pcre-dev Subject: 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 :
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
>