You gave me some ideas and directions to look atthank you Ze'ev Atlas
From: "p...@hermes.cam.ac.uk"
wrote
I'm not sure I can help without knowing more about what kind of API you
are defining. The ovector in the standard API is provided by the user as
part of the
On Sun, 5 Nov 2017, Ze'ev Atlas via Pcre-dev wrote:
> I need an adviceIn designing the conversion between EBCDIC code pages
> for PCRE2 I decided to make the API as simple as possible for the user
> and reduce overhead as much as possible. I am asking the user for
> example to tell me what is
Good Morning Phil
I need an adviceIn designing the conversion between EBCDIC code pages for PCRE2
I decided to make the API as simple as possible for the user and reduce
overhead as much as possible. I am asking the user for example to tell me what
is the estimated max length of the pattern
I guess that supply a conversion function (and API for non C users) is my only
option... yes the second option is too much maintenanceOnce fully recovered I
will work on it Ze'ev Atlas
From: "p...@hermes.cam.ac.uk"
To: Ze'ev Atlas
Cc: Pcre
On Thu, 19 Oct 2017, Ze'ev Atlas wrote:
> I am weighing my next step after realizing that the special characters
> for pattern cannot really change in runtime while being the most
> abused by IBM. IBM supplys a set of function that allow me to convert
> the input (string and pattern) from
I am weighing my next step after realizing that the special characters for
pattern cannot really change in runtime while being the most abused by IBM.
IBM supplys a set of function that allow me to convert the input (string and
pattern) from whatever EBCDIC codepage to the desired one. But in
On Wed, 18 Oct 2017, Ze'ev Atlas wrote:
> PhilI have encountered this issue. IBM did really bad job in creating
> the EBCDIC, especially as far as pattern matching is concerned. When
> they adapted EBCDIC to various languages they moved these symbols
> around like a whirpool. For example