Email List: Xaustin-group-lX
[All Lists]

Re: issue with XSH ERN 22 and XBD ERN 24

To: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: issue with XSH ERN 22 and XBD ERN 24
From: Finnbarr Murphy <yyyyyyyyyyyyyyy@xxxxxx>
Date: Thu, 23 May 2002 17:29:45 -0400
Organization: Hewlett-Packard Company
References: <200205231850.OAA0001348718@anw.zk3.dec.com> <1022184755.30693.250.camel@myware.mynet>
Ulrich Drepper wrote:
> 
> On Thu, 2002-05-23 at 11:50, Jack McCann wrote:
> 
> > The aardvark mentions 10 implementations, 9 of which implement 'int',
> > and 1 of which implements 'unsigned int'.  That's 90% and 10%, neither
> > of which is close to "half".
> 
> Half of the systems, not implementations.

What do you mean by half the systems?  Clearly if the majority of current 
implementations use int except for those systems which include glibc there 
is a real factual issue. To say otherwise is to be unreasonable. 

Is Solaris going to change? Is AIX going to change?  Is HP-UX going to 
change?
 
> Using unsigned int for flags is better engineering.  This was (according
> to a member of XNS working group) the reason for the change.  There is
> no typo.  It was also agreed on that the XNS text should be used and not
> POSIX.1g.  The text was up for review and was voted on.  Implementations
> changed accordingly.

No, not true. I believe only glibc has implemented the API per XNSv5.2 to 
date.

Furthermore, there is no clear evidence that XNET changed the IETF 
specification of the API and ignored existing practice for reasons of "better 
engineering." Where is the better engineering here?  Change the type of one API 
and ignore the rest of the APIs which use similar ints?  

This CR was in mail from Craig Metz dated July 25, 1999 subject "More CRs"

  Change Number: NRL:XNET-25
  Title: Major getnameinfo() definition problems
  Qualifier: Severity: Major Nature: Technical
  Rationale: The first sentence of getnameinfo() says: "looks up the IP address
  and port number..." This is already hopelessly protocol dependent wording.
  getnameinfo() is a protocol independent interface and an inverse operation to
  getaddrinfo().

  Major wording changes are needed to accomplish this.

  There are also a number of technical flaws in the specification. While I know
  that it would normally be preferably to enumerate and explain each change
  individually, in this case I really think doing the definition of this
function
  more or less from scratch is what's needed.
  Change:
  @70-74 Replace with:

  int getnameinfo(const struct sockaddr *sa, socklen_t salen,
                  char *node, size_t nodelen,
                  char *service, size_t servicelen,
                  unsigned int flags);
  .....

> And now you come in and complain.  It's too late. The decisions (the
> original one and the one about using it) was made deliberately and in
> line with all the guidelines of the working group.

Jack's position is entirely reasonable. Stability and longevity of APIs are 
important to end users.

Finnbarr
_____________________________________________________________________________
 Finnbarr P. Murphy    "Per Ardua ad Astra"    Email: yyyyyyyyyyyyyyy@xxxxxx 
 Office: ZK03-2/X23                                 Phone: +1 (603) 884-1517
 Hewlett-Packard Company, Nashua, NH 03062            Fax: +1 (603) 884-2257

<Prev in Thread] Current Thread [Next in Thread>