On 9/12/07, Karl Fogel <kfogel@red-bean.com> wrote:
> "Erik Huelsmann" <ehuels@gmail.com> writes:
> > I'll need to look at how we solved this in svn_ctypes.h, but as far as
> > I recall there were problems with exporting variables from DLLs on
> > Windows, because supposedly MSVC needs to reference a pointer to the
> > variable whereas other compilers support manipulating the variable
> > directly, see http://svn.haxx.se/dev/archive-2005-12/0364.shtml
>
> Hmm. I didn't quite understand that, and unfortunately svn.haxx.se is
> unreachable from my home network right now. We can't just define the
> object once in svn_iter.c, and then declare it "extern" in svn_iter.h?
> Does MSVC have a problem with that? (I thought it was standard C89.)
Oh, sure you can declare it as such, but it will only work with static
libs, not with DLLs. For DLLs you need to declare it with the MSVC
specific qualifier __cdecl(dllimport)/ __cdecl(dllexport). The
discussion I referenced concludes that the way ctyes was set up until
then was untennable. The end result is that ctypes was made internal
to libsvn_subr. (Although it looks like the header wasn't updated to
reflect that...)
> > I guess returning "(svn_error_t *)1" is the most portable solution to
> > returning a constant-and-known-pointer value to check against...
> >
> > Comments?
>
> Either one is fine, but having it be a real error object would be
> better, of course.
But only slightly: neither one nor the other can be passed to
svn_error_clear(); both will cause a SEGFAULT, the former because it's
an invalid pointer, the latter because it doesn't have a valid POOL
object in the pool field....
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 12 10:42:47 2007