[gnutls-dev] Re: Gnutls4win: Problem with custom push/pull functions, errno and Visual Studio (Workaround included)

[Simon Josefsson]

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.

Yup.

> 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
gnutls-msvcr71.dll?

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.

/Simon