emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] GnuTLS support on Woe32


From: Claudio Bley
Subject: Re: [PATCH] GnuTLS support on Woe32
Date: Mon, 14 Mar 2011 08:43:50 +0100
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Goj┼Ź) APEL/10.8 Emacs/24.0.50 (i386-mingw-nt5.1.2600) MULE/6.0 (HANACHIRUSATO)

At Sun, 13 Mar 2011 20:41:28 +0200,
Eli Zaretskii wrote:
> 
> > From: address@hidden (Claudio Bley)
> > Date: Sun, 13 Mar 2011 14:53:12 +0100
> > 
> > > If all you need is to produce EAGAIN when you have EWOULDBLOCK (the
> > > other mapping is already in set_errno), it hardly justifies a
> > > function.
> > 
> > That's true, WSAEINTR already gets mapped. Must have missed that.
> 
> So are we in agreement that a separate new function is not required?

Yes, absolutely.

> > > > > > > +static ssize_t
> > > > > > > +emacs_gnutls_pull(gnutls_transport_ptr_t p, void* buf, size_t sz)
> > > > > > 
> > > > > > Can we move the Windows-specific functions to w32.c, and only call
> > > > > > them from gnutls.c?  I think we want to keep the Windows-related 
> > > > > > code
> > > > > > outside w32*.c to the bare minimum.
> > > > > 
> > > > > OK.
> > > > 
> > > > Maybe the GnuTLS specific stuff should also be kept to the bare
> > > > minimum outside of gnutls.c?
> > > 
> > > What stuff did you have in mind?
> > 
> > All the GnuTLS related functions (even if Windows specific).
> 
> That's not what we do in Emacs.  OS-specific #define's are best kept
> to a minimum, the sole exception being sysdep.c.  Otherwise, we try to
> keep code of non-Posix and niche platforms on their specific sources
> files.

It's just that these functions are not really OS-specific in any
way. I'd rather say they are GnuTLS specific.

> > > > Considering that these functions would have to be non-static in this
> > > > case to be accessible by gnutls.c.
> > > 
> > > Sure, but I see no problem with that.
> > 
> > I'm usually a bit reluctant to create public functions in a module
> > which only serve a special purpose in one single other module.
> 
> Why?  Emacs is a program, not a general-purpose library.  Invading
> some unknown namespace should not be an issue.

Never mind. I'm OK with moving them to w32.c. Consider this done.

- Claudio





reply via email to

[Prev in Thread] Current Thread [Next in Thread]