Hi Sheri,
Is this ok:
Index: pcre_jit_test.c
===================================================================
--- pcre_jit_test.c (revision 694)
+++ pcre_jit_test.c (working copy)
@@ -40,9 +40,12 @@
-----------------------------------------------------------------------------
*/
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
#include <stdio.h>
#include <string.h>
-#include <time.h>
#include "pcre.h"
#define PCRE_BUG 0x80000000
By the way, my name is in Hungarian naming order, thus Zoltan is my first name and prefer to use that :)
Regards,
Zoltan
Sheri <silvermoonwoman@???> írta:
>Hi Herczeg,>
>
When I tried building static libraries I encountered a problem building >
pcre_jit_test, because on Windows, PCRE_STATIC must be defined before >
including pcre.h>
>
I think in order to ensure that PCRE_STATIC gets defined or not as >
appropriate for the configuration, the pcre_jit_test program should >
include config.h>
>
Regards,>
Sheri>
>
On 9/14/2011 6:58 PM, Sheri wrote:>
> Yes! when patched RunTest succeeds fully when run in the Unix-like >
> Msys console.>
>>
> Regards,>
> Sheri>
>>
> On 9/14/2011 5:37 PM, Herczeg Zoltán wrote:>
>> Hi All,>
>>>
>> After some thinking I feel I found the issue. CMakeLists.txt revealed >
>> that NEWLINE can be -1 or -2, which are special constants for ANY and >
>> ANYCRLF, not a plain newline code. During the debugging the newline >
>> was compared to -2, which is obviously failed.>
>>>
>> My code was:>
>>>
>> switch(re->options& PCRE_NEWLINE_BITS)>
>> {>
>> case 0: common->newline = NEWLINE; break; /* Compile-time >
>> default */>
>> ...>
>> }>
>>>
>> This is wrong. I need to check the NEWLINE constant first, whether it >
>> contains -1 or -2, and not simply assign it to a value.>
>>>
>> A fix is attached to this mail. It is compressed to avoid newline >
>> issues xD>
>>>
>> Sheri could you try it on your machine?>
>>>
>> Thanks,>
>> Zoltan>
>>>
>> "Herczeg Zoltán"<hzmester@???> írta:>
>>> Hi Sheri,>>
>>>>
>> I did some assembly level debugging and I had an impression that >
>> something might be wrong with the NEWLINE macro.>>
>> I have added some debug printf-s to the pcre_jit_compile.c. Could you >
>> compile the reduced pcre_jit_test program again with this debug >
>> compiler and send me the output?>>
>> Thanks in advance,>>
>> Zoltan>>
>> Sheri<silvermoonwoman@???> írta:>>
>>> On 9/14/2011 1:50 PM, Herczeg Zoltán wrote:>>>
>>> Hi Sheri,>>>
>>> I agree something messed up with new line recognizing. The failing >
>>> native pcre_jit_test test is also newline related. I made a simple >
>>> test case for you, attached to this mail. Please replace the >
>>> original pcre_jit_test.c, and compile this new one. Please compile >
>>> it as a standalone, debug binary and send it to me so I can do the >
>>> debugging myself.>>>
>> I tried to do that, copied in your new source and elected static debug>>>
>> and other options. I had to add #define PCRE_STATIC before your >
>> includes>>>
>> to get it build. There is some discussion about PCRE_STATIC in >
>> pcredemo.c>>>
>> After that change it built ok. A zip of the exe is attached. FYI, the>>>
>> corresponding pcretest program reports the following:>>>
>> > pcretest -C>>>
>> PCRE version 8.20-RC1 2011-09-12>>>
>> Compiled with>>>
>> UTF-8 support>>>
>> Unicode properties support>>>
>> Just-in-time compiler support>>>
>> Newline sequence is ANYCRLF>>>
>> \R matches CR, LF, or CRLF only>>>
>> Internal link size = 2>>>
>> POSIX malloc threshold = 10>>>
>> Default match limit = 10000000>>>
>> Default recursion depth limit = 10000000>>>
>> Match recursion uses heap>>>
>>>>>
>> The following case is strange to me:>>>
>> re> /^abc$/mS>>>>
>> data> abc\nzzz>>>>
>> No match>>>>
>> It should study the pattern but should not do any JIT compiling.>>>
>> But since the JIT compiling has already been done, it must have used >
>> it.>>>
>> It started with a clean slate once pcretest was restarted.>>>
>>>>>
>>
>
