Thanks guys, I was and am merely trying to user-test an application and
wanted to use pcretest to give me the "right" answers. Should it concern
me if the code size for the same pattern testing in pcretest and the
application do not match? For "a" I get 9 in pcretest and 49 in the
application.
Also, I would like to distribution interim updates but cannot prepare
the html documentation (no groff). Phillip would it be possible for you
to automatically trigger updates to the html versions when you update
the doc files?
Finally, I use ViewVC for viewing the development files. I see on the
Help page that one of the ViewVC configuration options would enable
downloading tarballs. It would be useful to me if that could be enabled,
unless there are other concerns that preclude that.
Regards,
Sheri
On 12/1/2011 9:04 AM, Zoltán Herczeg wrote:
> Hi Sheri,
>
> this memory size of the executable code is an interesting idea. Do you need it for statistical purposes? Actually the JIT does not store the size of the executable size (and you still cannot save and restore this block), only the executable allocator knows the size.
>
> The easiest way to do this is simply ask the allocator. However, if someone ever want to change the allocator (which is possible), it is unlikely that the other allocator has this feature (funny, that although the allocators know everything about any memory block, they don't share it with the userland). Perhaps I can save the allocated executable block size during the final compilation phase, and return it (although the total executable memory allocated by the executable allocator would still be unknown).
>
> Regards,
> Zoltan
>
> PS: supporting 16 bit is quite time consuming, so it will take a while to do it.
>
> Philip Hazel<ph10@???> írta:
>> On Tue, 22 Nov 2011, Sheri wrote:>
>>
>> Trying various patterns via console use of pcretest, I noticed that apparently>
>> once /S+ has been used on an re, JIT study is either being applied to>
>> subsequent patterns that use /S or it is being reported despite not being>
>> used.>
>>
> Oops. That was a trivial oversight, which I have now fixed. (I should>
> have see it; it showed up in test 14.)>
>> Also I noticed that pcretest has /M is available to give code size; is there>
>> any pcretest option that gives study size?>
>>
> No, this information hasn't ever been made available. In fact, for>
> non-JIT study, the size is small and fixed (and is, if I've counted it>
> right, 76 bytes on a 32-bit machine - this includes the pcre_extra block).>
>> If JIT is successful, is the compiled pattern size reported the JIT size of>
>> the compiled pattern, or is that part of what would be returned from>
>> pcre_fullinfo for PCRE_INFO_STUDYSIZE?>
>> IOW is it odd that I see the same code size for unstudied and jit-studied>
>> versions of the same pattern?>
>>
> No, it's not odd. The size reported by pcre_fullinfo (and therefore by>
> pcretest) is the size of the compiled pattern not including the results>
> of the JIT compilation. I guess I should (a) document this and (b) draw>
> it to the attention of Zoltan (though he is busy working on 16-bit>
> support at the moment).>
> Philip>
> -- >
> Philip Hazel>
> -- >
> ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev>
>
>
