[gnutls-dev] Re: Gnutls4win: Problem with custom push/pull
functions, errno and Visual Studio (Workaround included)
jas at extundo.com
Mon Nov 6 15:46:29 CET 2006
Werner Koch <wk at gnupg.org> writes:
> On Mon, 6 Nov 2006 12:47, jas at extundo.com said:
>> value before using the value in errno. However, it seems harmless to
>> set errno to 0 before the call, and it might catch errors in custom
> If you want gnutls to behave similar to Posix or ISO-C, you should not
> set errno to 0.
Agreed. Since it is now proved to be harmful to set errno 0 here,
I've reverted that part of the patch.
> Posix states that errno will be not be set to 0 by any function
> decribed in this volume of IEEE-1003.1. Setting errno to 0 without an
> error changes the semantics.
> if ( open (...) < 0 )
> gnutls_foo ()
> fprintf (stderr, "error from open: %s\n", strerror (errno));
> Should print an error if open fails. The printed error will be from
> open or due to a failure of gnutls_foo. If gnutls_foo succeeds, the
> result would be a
> error from open: No Error
> That is probably not what the user expected.
> Anyway, mixing different CRTs is not exactly a good idea. You will
> encounter more and more problems which are even harder to solve. We
> have the same problem with gpgol (an Outlook extension), however
> Outlook handles extensions a bit different than a plain DLL and thus
> the "only" problem we had to solve was to use the correct version of
> free(). IIRC, the DLL mechanisms has some indirect linking features
> whoch might be used to solve this problem.
I remember the free() problem from libidn, and it now has a similar
dummy function idn_free() that simply calls free().
Anyway, what are the additional problems and what is the correct
solution to the entire mess?
Not linking to any CRT at all? I wonder how much from the CRT gnutls
actually needs, it might be possible...
Providing more than one gnutls DLL? E.g., gnutls-mscvrt.dll and
Any other solutions?
Perhaps it would be useful to have a build option to build gnutls to
not use send/recv/errno at all. Then the caller must always supply
its own send/recv functions. That build option should be easy to add.
I suspect that this patch goes a long way to fix things, though.
More information about the Gnutls-dev