[Privoxy-devel] PATCH for pcre2 support
    Gagan Sidhu 
    broly at mac.com
       
    Thu Mar  9 15:43:07 CET 2023
    
    
  
the sha256 is now:
c8b91bba127f7b3e2276bee156acec3753c0ebab61dd8fbd24f22cbb1bc6e1a4 
because i forgot to update the ovector pointer after pointing to the new allocation, which we would presumably need to do.
sorry about all the spam.
Thanks,
Gagan
> On Mar 9, 2023, at 7:36 AM, Gagan Sidhu <broly at mac.com> wrote:
> 
> 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
>> 
> 
    
    
More information about the Privoxy-devel
mailing list