[Privoxy-devel] PATCH for pcre2 support

[Gagan Sidhu]

hi fabian,

i also noticed i was not freeing this new struct pcre2_matches which may also cause problems.

i have now inserted the free calls where the original matches structure is being freed.

i also use a new variable, pcre2_matches_dummy, to create a new pcre2_match_data structure of the new size.

the only issue may be that we cannot simply memcpy the original contents the way i have done, i,e:

> memcpy(pcre2_matches_dummy,pcre2_matches,pcre2_get_match_data_size(pcre2_matches));
 
but i will leave that up to the readers. i don’t see, 
	-theoretically, why this would be an issue.
		-the type of the source and destination is the same, but it’s possible we need to iterate through.

new sha256 should be
> a2e39358ce779561c6599b4809e82ae3914965ea165c93368abd80c31af03799


i hope this fixes things instead of making them worse. :P

Thanks,
Gagan

> On Mar 9, 2023, at 7:03 AM, Gagan Sidhu <broly at mac.com> wrote:
> 
> that sum looks right.
> 
> and re name: i sure can, and i just did.
> 
> i personally do not use privoxy, but i know others do.
> 
> re: cgi issue: i think it’s possible this is caused when the matches exceed the initial size.
> 
> that is, in this portion of the code:
> 
>>         max_matches = (int)(max_matches * PCRS_MAX_MATCH_GROW);
>> 
>>         if (NULL == (dummy = (pcrs_match *)realloc(matches, (size_t)max_matches * sizeof(pcrs_match))))
> 
> because the pcre2_match_data structure would also need to be resized, and i haven’t done that yet because i just realised this :P
> 
> problem is, i don’t know if it’s that simple because we are using the pcre2 library’s allocation.
> 
> or does the CGI not use the pcrs_execute function?
> 
> Thanks,
> Gagan
> 
>> On Mar 9, 2023, at 6:17 AM, Fabian Keil <fk at fabiankeil.de> wrote:
>> 
>> Gagan Sidhu <broly at mac.com> wrote on 2023-03-09 at 06:09:50:
>> 
>>> yes i just updated that exact patch (deleted, reuploaded) and it should now be:
>>> 
>>> 106592f5e18ded8f6516d98522b9bbfd10185e40  shitty_pcre2.patch
>>> 
>>> i suspect, or hope, this will fix the cgi issue, just because of how i ignored the usage of the dummy variable in the first patch.
>>> 
>>> if it works, the other two warnings need to be fixed by changing the declarations of the variables passed to the function itself.
>> 
>> I now get:
>> 
>> fk at t520 ~/git/privoxy $sha256 shitty_pcre2.patch 
>> SHA256 (shitty_pcre2.patch) = 10eb42d03de0ccfdee4a4593f2848ca7193b30bcb8547febc0b7ff8d9f8766a7
>> 
>> and the CGI issue still exists.
>> 
>> Can you please upload the patch with a different name?
>> 
>> Fabian
>