[ksh93-integration-discuss] Re: [ast-users] /dev/tcp+/dev/udp notcompiled-in for Solaris ksh93r...

[James Carlson]

Alan Coopersmith writes:
> Roland Mainz wrote:
> > Some questions (CC:'ing Casper to have a look at the problem, too):
> > - AFAIK none of { Xorg, Xsun, Mozilla. FireFox, KDE, Kerberos5, bash }
> > uses libxnet... the question is: Why can't they use libxnet ?
> 
> For Xorg & Xsun, we use libsocket+libnsl simply because we've always
> used libsocket+libnsl and no one has ever suggested that there would
> be a single iota of benefit in switching to libxnet.   Until this
> conversation, I always thought libxnet was there strictly for XPG
> standards conformance, and wasn't intended for use by native Solaris
> applications.

Not quite so.  XPG provides some important features over the stale old
libsocket implementation -- particularly the use of ancillary data --
and is thus required by some native Solaris applications.

There are some things missing from libxnet, but I suspect they're
mostly accidents rather than intentional, and could be repaired with a
little care.

Backing up a bit, what I was pointing out here wasn't that folding
libxnet functionality in was in any way trivial, but rather that we
need to be very careful in what we decide to bring over to libc,
regardless of how upset we might be at the present annoyance of
-lsocket -lnsl.  Once we bring it in, there's no going back.

With that in mind, I'd much rather see the richer standards-conformant
environment become the default, and have applications that need to
wander off into the weeds by specifying "-lsocket -lnsl" do so
explicitly.  Using -lsocket as the default, no matter how common it
might seem, looks like a big step backwards to me.

The sticky parts are the #ifdef'd goop in the header files, not the
libraries themselves.  It's non-trivial, but I suspect that it could
be pulled off if we're willing to accept some corner cases that result
in source incompatibility.

-- 
James Carlson, KISS Network                    <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677