Subject: (IPng 6664) Re: Base API Edit Question on error_num

From: Mukesh Kacker <[email-masked]>
Date: Wed, 21 Oct 1998 18:33:21 -0700 (PDT)

> 
> error_num is what you want it to be and there is confusion with
> h_errno. 
>

What could be confusing people is a design decision to use the
same "error code name space" by getipnodebyname() as the one
used for "h_errno". [ i.e. the constants HOST_NOT_FOUND, NO_ADDRESS etc].

That has been done for ease of porting. However (as Jim stated) use of
"global" variables is deprecated and here the application has to use
its own local variable to store the error which is the more modern
practice in world with threads (the dereference to function returning
modifiable lvalue hack notwithstanding).

Similar approach has been taken in the  getaddrinfo() function where
the error is passed back as return value [i.e the EAI_* error namespace ]
but does not set any "global" variable.

[ While we are on this topic...there is another thing someone here noticed
recently. The getnameinfo() function has punted on defining errors. Not sure if
this was "by design" or the intent was to work out the important details
and leave error codes and such to the standards folks (Posix, XNET etc).
It just says "non-zero ...indicates failure" If a complete error namespace
is ever to be done, there will have to be an ENI_* error namespace (similar
to EAI_* errors) and a gni_strerror() function (similar to gai_strerror()).
Not sure if anyone would be tackling that at this stage :-)  The "reference
implementation" in Richard Stevens Unix Network Programming book chooses to
return "1" for all error scenarios in getnameinfo() even though getaddrinfo()
has meaningful getaddrinfo() error codes. ]

-Mukesh Kacker
 Sun Microsystems Inc.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked] (Sam Manthorpe)
Date: Wed, 21 Oct 1998 18:55:35 -0700 (PDT)

> modifiable lvalue hack notwithstanding).

Yes, I appreciate that.  I was never suggesting that h_errno replace
error_num as a general means of communicating error types.  All I was
saying was that the text that gives an example of how to modify an app
to work with IPv6 could imply that this simple change is all that 
is required and that the app may continue to use h_errno elsewhere
in the code.  

I originally proposed to replace error_num with h_error in the example, 
but have since realised that this would be misleading and could be 
interpreted as saying `one should use h_errno to store error values 
returned by getipnodeby*()'.  That wasn't at all what I meant.  Anyway, 
it's really a minor thing and probably not worth discussing at this much 
length ;-)

-- Sam

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 21 Oct 1998 21:55:36 -0400

Mukesh,

On getXXinfo parts.  This is a POSIX reference and we (the IETF IPng WG)
don't own it and can't change it, us changing it would be like the IEEE
1394 folks changing our IP over Foo specs to suite that standard. It
stands as it is per the reference. 

We have limititations here for this work it will not solve all problems,
it is mean't to get IPv6 deployed by applications, we have stretched that
quite far since I first saw Bob Gilligan's draft in 1993 for this API.
I think we should stop stretching it and ship it.

I believe when we decided to replace gethostbyname with a new incantation
that would be MT safe we basically trashed h_errno, because there is
no market, standard, or implementation consensus it is not a global
variable and can be a MT Safe error mechanism.  

/jim