Re: Release date for Privoxy 3.0.19 stable

On 12/30/11, Fabian Keil <[email protected]> wrote:
> Lee <[email protected]> wrote:
>
>> On 12/29/11, Fabian Keil <[email protected]> wrote:
>> > Lee <[email protected]> wrote:
>
>> >> Does the internal pcre version have modifications to handle the host
>> >> part of regular expressions in the action files or is it two separate
>> >> functions?  eg
>> >> .example.com/
>> >> matches any host name ending in ".example.com".  A normal [??] RE
>> >> would treat the periods as match any single character.  Privoxy
>> >> doesn't treat periods as wildcards until after a "/" character.
>> >
>> > No such modifications are necessary as Privoxy doesn't use
>> > pcre for the host part of the URL pattern at all,
>>
>> ??
>> It seems like it has to use something since it isn't a straight text
>> match..
>> Oh well, I'll try to follow the code & figure it out
>
> Have a look at host_matches() in urlmatch.c.

Thank you.  I took a quick look & it felt like learning string
processing in assembler all over again.  I've got relatives visiting,
so I doubt that I'll be able to seriously look at it for at least a
week.


>> Where I was trying to go with the question was finding out if there's
>> two separate packages - "host patterns" and whatever comes after the
>> host part.  If it's all one package with modifications for matching
>> host patterns then upgrading to the current PCRE libs + backporting
>> Privoxy modifications to the library is going to be *much* harder.
>>
>> If it's two separate packages there's a slightly better chance I can
>> figure out how to upgrade the windows version of Privoxy to the
>> current pcre library.
>
> It should in theory work similar to the way the external
> zlib is used:
>
> 1. Install a recent pcre version and its header files.
> 2. Figure out a way to convince configure that a dynamic
>    pcre version is available. It might work out of the box
>    or require some fiddling.
> 3. Get it to compile. Again, it might just work.
> 4. Figure out a way to get the compiled binary working
>    when installed from a package. This might require
>    shipping a dll for pcre.

I'm using the cygwin 1.5 environment for building Privoxy.  I'll take
another stab at upgrading to cygwin 1.7 cross-compiler in a week or
two (cygwin dropped support for --enable-mingw32 when they released
1.7 and GCC 4.x, so to get a current pcre library I'm guessing that I
need to figure out the cygwin cross-compile stuff or figure out how to
use mingw)

> The alternative would be to update "our" pcre version
> and to continue statically compiling pcre into the
> Privoxy binary.

I'm assuming you've tried linking privoxy with the pcre library on
your machine.  Did you have any issues with old action file regexs and
new pcre libs?
For example, I had a problem with regexs not working in awk after
upgrading to cygwin 1.7  Turns out they enabled support for multiple
languages in 1.7 and ranges like [a-z] didn't work until I set LANG=C

>>    [.. snip domain regex possible options ..]
>> >> >> > Interesting. We probably shouldn't use that define when
>> >> >> > --disable-ipv6-support has been used anyway.
>> >> >>
>> >> >> Probably not.. dunno if it's worth the effort to redo the code when
>> >> >> we
>> >> >> could just do a
>> >> >> #ifndef NI_MAXSERV
>> >> >
>> >> > Using our own define, naming it to something like
>> >> > MAX_PORTSTRING_LENGTH and setting it to NI_MAXSERV
>> >> > if it's available, and 32 otherwise, would also make
>> >> > the code easier to read (I think), so I'd consider it
>> >> > worth it.
>> >>
>> >> Whatever you think is best.  I got lost trying to figure out how
>> >> configure did it's thing & ended up putting the define of NI_MAXSERV
>> >> in jbsockets.c
>> >
>> > configure has no magic to satisfy the requirement for a
>> > NI_MAXSERV definition in jbsockets.c if IPv6 is disabled.
>>
>> Not that I could follow it, but it sure seems to create header files.
>
> It creates the config.h with various defines through which
> other header files are included (or not).
>
>> I was thinking it'd be nice if all the required header files were
>> pulled in regardless of IPv6 being enabled or not & leaving out the
>> WinXP and later library calls if IPv6 was disabled.
>
> Which header files are required depends on on which features
> are enabled. Some of the header files required for IPv6
> aren't available on systems without IPv6 support, so they
> can't be always included or you'd get compile errors even
> if no IPv6-specific functions are called.
>
> For example <winsock2.h> and <ws2tcpip.h> are probably
> not available on older Windows versions, so they can't
> be always pulled in.

I was going to ask why not pull in the headers if they exist on the
build machine, but I guess the better work-around is adding the
  #ifndef NI_MAXSERV
since it fixes the problem for both the with & without header files
build environment.

Thanks,
Lee

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox