> -----Original Message-----
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: zaterdag 12 september 2015 14:09
> To: dev@serf.apache.org
> Subject: Re: [serf-dev] [serf] r2489 committed - In preparation of serf 1.4.0,
> remove the get_remaining function from t...
>
> [redirected to dev@serf]
>
> On Mon, Apr 6, 2015 at 8:32 AM, Bert Huijben <b...@qqmail.nl> wrote:
>
<snip>
> 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?
Yes, see the other mail explaining the cases when you can see this.
(Proxy functions calling into shared libraries, etc.)
And I even found a case where two functions with different names but identical
behavior returned the same value. (When using link time code generation; part
of full program optimization)
> 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).
Currently all the vtable implementations are static. How are we going to
publish the 'type' for this, to pass to the function as argument?
Sharing data from shared libraries introduces new problems... perhaps using a
helper function to obtain the value to pass?
I don't think we want to have that implementation hidden in a macro any more if
there is so much processing inserted.
> 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.
This really depends on how you declare it. With the right .def and/or
__declspec() magic this can work, but it still feels like a hack.
Can't we just extend serf_bucket_t with a type2 variable at the end?
(It looks like we have only one places where we allocate these, when I ignore
the trunk log bucket hacks... which would already break if some other bucket
did the same trick)
We can then just rev serf_bucket_create() to set type and typ2 to the same
variable.
Bert
