On Mon, Mar 21, 2011 at 12:23, Guenter Knauf <fua...@apache.org> wrote:
> Greg,
> Am 21.03.2011 15:38, schrieb Greg Stein:
>...
>> I'm a committer on Expat, but (as you've noted) the project has had no
>> attention for quite a while. I wasn't aware of a security problem in
>> there, however.
>>
>> Even if I dropped a new release of Expat, would we want to rely on the
>> external build (and latest release being propagated) or continue to
>> ship a patched Expat within APR?
>>
>> Switching to libxml2 would be possible (it is MIT licensed), but would
>> require a lot more coding work in the xml support. Users of APR (1.x)
>> also depend on Expat being available, and a switch would require them
>> to rewrite their XML parsing code. Maybe that is acceptable for apps
>> to switch to 2.0?
>
> I followed up with libxml2 for a while on NetWare, and every now and then
> compilation was broken with next release due to not only fixing bugs but
> also adding a bunch of new features which then require futher tweaks (search
> for stubs which provide missing OS functions in network layer, etc).
> Further more many projects dont care about issues with compilers which dont
> like declarations after statements, and often you then end up with
> uncompilable code :-(
Yeah. In Subversion, we have a bunch of Windows developers, and they
call out when declarations occur after statements :-)
>> In short: I can make a release happen, but would that matter to the APR
>> project?
>
> when I tried to compile for Win32 with Watcom C I had to add this to expat:
> --- expat.h.orig Mon Nov 27 03:51:58 2006
> +++ expat.h Mon Aug 09 16:27:36 2010
> @@ -193,11 +193,19 @@
> XML_XmlDeclHandler xmldecl);
>
>
> +#if defined(WIN32) && defined(__WATCOMC__)
> +typedef struct {
> + void * __watcall (*malloc_fcn)(size_t size);
> + void * __watcall (*realloc_fcn)(void *ptr, size_t size);
> + void __watcall (*free_fcn)(void *ptr);
> +} XML_Memory_Handling_Suite;
> +#else
> typedef struct {
> void *(*malloc_fcn)(size_t size);
> void *(*realloc_fcn)(void *ptr, size_t size);
> void (*free_fcn)(void *ptr);
> } XML_Memory_Handling_Suite;
> +#endif
Seems reasonable. There have been a number of other little compilation
bug reports that have crept in over time. Could probably spend a day
just closing out those issues.
> /* Constructs a new parser; encoding is the encoding specified by the
> external protocol or NULL if there is none specified.
>
> BTW. is there a public repo from where oen can fetch current code?
http://sourceforge.net/scm/?type=cvs&group_id=10127
> oh, and while on things to fix where you are commiter:
> another one who plays with httpd and subversion on NetWare told me that
> current code of libserf has its quirks on NetWare - are you willing to take
> a look into that before we go for httpd GA?
I don't see how httpd GA is related to serf?? ... certainly, you want
serf fixed up for a NetWare Subversion. But does httpd 2.4 consume
libserf nowadays? (ie. one of the proxy modules?)
> And where to post patches? To you directly?
serf-...@googlegroups.com
and/or open issues at code.google.com/p/serf/
Cheers,
-g
