Hi,
Also IMHO for *new* API we shouldn't continue the problems of the old
APIs; that means we should use size_t for the length, start_offset and
offsetcount parameters and the offsets themselves. (If the current code
can't cope, just reuturn an error if length INT_MAX, but then we can
fix
On Sun, 30 Sep 2012, Zoltán Herczeg wrote:
Also IMHO for *new* API we shouldn't continue the problems of the old
APIs; that means we should use size_t for the length, start_offset and
offsetcount parameters and the offsets themselves. (If the current code
can't cope, just reuturn an error
On 22 September 2012 12:43, Zoltán Herczeg hzmes...@freemail.hu wrote:
Dear devs,
I have been thinking for some time, that the point of JIT is offering
outstanding pattern matching performance (and it improved a lot lately) and
it is still used through pcre_exec. So I am planning the add a
But out of curiosity, how come that pcre_exec can't just do what this
function is supposed to do when it has a JIT-compiled pattern, UTF
checks are not requested, etc.?
The point of the new API is not inventing something which was not possible
before. Instead, it increases the performance of
--- You are receiving this mail because: ---
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1301
Christian Persch (GNOME) c...@gnome.org changed:
What|Removed |Added
