[redirected to dev@serf] On Mon, Apr 6, 2015 at 8:32 AM, Bert Huijben <b...@qqmail.nl> wrote:
> > -----Original Message----- > > From: serf-...@googlegroups.com [mailto:serf-...@googlegroups.com] On > > Behalf Of s...@googlecode.com > > Sent: maandag 6 april 2015 11:25 > > To: serf-...@googlegroups.com > > Subject: [serf-dev] [serf] r2489 committed - In preparation of serf > 1.4.0, > > remove the get_remaining function from t... > > > > Revision: 2489 > > Author: lieven.govaerts > > Date: Mon Apr 6 09:24:18 2015 UTC > > Log: In preparation of serf 1.4.0, remove the get_remaining function > > from the > > bucket API. > > > > This reverts most of r2008, r2009, r2010 and r2198. From r2008 I kept the > > read_bucket_v2 function, which is needed for set_config. > > If we still keep the read_bucket_v2 feature, what is the reason for just > removing get_remaining? > > > We still have to handle the linkage problems if we use the > read_bucket_v2() system for versioning, but we leave out the tests that > were added to find problems caused by different function pointers. > > > The reason we see errors on this feature on several platforms is just this > linkage problem, while the get_remaining code itself is pretty stable as > far as I can tell. I'm guessing that the reason for removing the code is > that we see this errors. > > > Our scons scripts make us link both the static library and shared library > versions of the same functions, and then a simple pointer comparison on a > function pointer isn't going to work as expected. > > > And with a shared library build, there are other possible problems: > sometimes you get a pointer to a wrapping function... or the pointer value > is not guaranteed because the code might be moved under some circumstances > (unload+load of library) > So you're saying that a pointer to a specific function might have *two* values under Windows? Within a single executable? That A could see a different value from B? Assuming that is the case (or we wouldn't be in this situation), then let's change how v2 is API-compatibly detected. Again, let's use read_bucket() since it gives us a lot of flexibility and nobody has ever used it. Let's define a "V2_API_BUCKET" type and then ask for bucket FOO to return one of those. If FOO's type has a NULL read_bucket pointer, or returns NULL for that bucket type, then it is V1. If FOO's type has been updated, then it *can* return a V2 bucket (which does nothing; could be a static const data struct). That will skip any function pointer comparisons. We *do* switch to a data value (serf_bucket_type_v2_api), but I'm guessing Windows *does* have a singular constant value for that within the program space. Will this work? Cheers, -g
