DIRegEx v8.10.0 for Delphi 10.3 Rio Cracked

DIRegEx v8.10.0 for Delphi 10.3 Rio Cracked

DIRegEx v8.10.0 for Delphi 10.3 Rio Cracked
DIRegEx v8.10.0 for Delphi 10.3 Rio Cracked


DIRegEx is a library of components and procedures that implement regular expression pattern matching using the same syntax and semantics as Perl for Delphi (Embarcadero / CodeGear / Borland).

DIRegEx offers two regular expression algorithms with their corresponding wrapper classes for easy usage:

TDIPerlRegEx implements a matching algorithm with the same syntax and semantics as Perl. Consider this the standard algorithm which you are used to from Perl and j@vascript. It is very fast and supports the complete pattern syntax. You will very likely be using it most of the time.

TDIDfaRegEx implements the DFA matching algorithm. Considerer this as a special purpose algorithm. If finds all possible matches and in particular, it finds the longest. It never needs to backtrack and supports partial matching much better, even for very long subject strings in several pieces.

Both classes descend from a common ancestor TDIRegEx which implements the complete functionality for working with regular expressions, regardless of which algorithm is currently in effect:

Matching and extraction of matches / substrings from the source text.
Searching for regular expressions within streams and memory buffers. To search within streams or files (of virtually unlimited size), use one of the specially optimized TDIRegExSearchStream class descendents.
Replacements on full and partial matches / substrings.
Listing of full and partial matches / substrings.
Formatting of matches.

DIRegEx 8.10.0 – 7 Mar 2019
Fix: TDIRegEx.Replace and TDIRegEx16.Replace did not return the start of the string if StartOffset > 0.
Adjust TDIRegExSearchStream_Enc to DIConverters 1.18.0: Converter functions now use the native unsigned integer type for the length of a string and support stings longer than 2 GB. This change only affects projects using DIConverters.
In a pattern such as [^\x{100}-\x{ffff}]*[\x80-\xff] which has a repeated negative class with no characters less than 0x100 followed by a positive class with only characters less than 0x100, the first class was incorrectly being auto-possessified, causing incorrect match failures.
If the only branch in a conditional subpattern was anchored, the whole subpattern was treated as anchored, when it should not have been, since the assumed empty second branch cannot be anchored. Demonstrated by test patterns such as (?(1)^())b or (?(?=^))b.
Fix subject buffer overread in JIT when UTF is disabled and \X or \R has a greater than 1 fixed quantifier.
If a pattern started with a subroutine call that had a quantifier with a minimum of zero, an incorrect “match must start with this character” could be recorded. Example: (?&xxx)*ABC(?<xxx>XYZ) would (incorrectly) expect 'A' to be the first character of a match.
Using pcre_dfa_exec, in UTF mode when UCP support was not defined, there was the possibility of a false positive match when caselessly matching a “not this character” item such as [^\x{1234}] (with a code point greater than 127) because the “other case” variable was not being initialized.
Although pcre_jit_exec checks whether the pattern is compiled in a given mode, it was also expected that at least one mode is available. This is fixed and pcre_jit_exec returns with PCRE_ERROR_JIT_BADOPTION when the pattern is not optimized by JIT at all.
If a backreference with a minimum repeat count of zero was first in a pattern, apart from assertions, an incorrect first matching character could be recorded. For example, for the pattern (?=(a))\1?b, “b” was incorrectly set as the first character of a match.
Fix out-of-bounds read for partial matching of . against an empty string when the newline type is CRLF.
Matching the pattern (*UTF)\C[^\v]+\x80 against an 8-bit string containing multi-code-unit characters caused bad behaviour and possibly a crash.


Home:
http://www.yunqa.de/delphi/doku.php/products/regex/index


Only for V.I.P
Warning! You are not allowed to view this text.


Information
Users of Guests are not allowed to comment this publication.