Subject: (IPng 6658) Base API Edit Question on error_num

From: [email-masked]
Date: Wed, 21 Oct 1998 09:46:54 -0400

Folks,

Quick editing question.  We have gotten several inputs folks would like
to use h_errno from multiple implementors.

We don't really care if that is what folks want?  

Can we hear from you?

>> applications.  That is, porting simple applications to use IPv6 replaces
>> the call
>> 
>>    hptr = gethostbyname(name);
>> 
>> with
>> 
>>    hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
>
>Wouldn't a more accurate equivalent actually be:
>
>    hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &h_errno);
						       ~~~~~~~~
thanks
/jim
--------------------------------------------------------------------
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 14:15:17 -0400

Here is some private input I got on h_errno from a die hard implementor.
This was my first impression but I have not worked with the
gehostbyxxx_r routines hands on as an implementor, so I am listening.

------------------------
Bad idea.  h_errno is a global variable, not thread safe, the
whole reason for adding the "&error_num" parameter is to move
away from using h_errno.  That said, people could pass in
&h_errno if they wanted to, but I don't think we want to encourage
that usage.  I'd stick with &error_num.  The prototype is just
an example anyway, people can pass in whatever 'int *' name they
want.
-----------------------------

/jim

---

From: [email-masked]
Date: Wed, 21 Oct 1998 14:55:32 -0500

Ho.

	It may have been mentioned already, but h_errno is not 
necessarily a global, and may already be thread safe in a number of
implementations (it is in ours).

-andrew

-- 
+---------------------------------------------------------------------------+
| Andrew Kephart, AIX TCP/IP        These are my opinions only...IBM might  |
| SMTP: [email-masked]     agree, but I wouldn't count on it.      |
+---------------------------------------------------------------------------+

---

From: [email-masked] (Sam Manthorpe)
Date: Wed, 21 Oct 1998 13:10:15 -0700 (PDT)

> gehostbyxxx_r routines hands on as an implementor, so I am listening.

I see your point; but if anybody blindly follows the example that the
draft gives of replacing gethostbyname() with  getipnodebyname(),
any code that subsequently used h_errno would not give the expected
result.  Moreover, such code wouldn't be thread safe anyway if it's
using gethostbyname.  Maybe the text should be something like:

> and changes any subsequent error diagnosis code to use error_num instead
> of externally declared variables, such as h_errno.

Or maybe this is just too obvious?

-- 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 20:52:25 -0400

Sam,

>Or maybe this is just too obvious?

It was to me but that don't count.  I can put this in if we don't change
it to h_errno.  Right now consensus seems split to me, with people using
h_errno in different ways as a variable on their implementations. 

There is no backwards compatibility requirement for this API spec until
this spec itself moves forward.  So saying h_errno is needed for
backwards compatibility is an argument I don't see right now as valid.
So we are starting from scratch.

error_num is what you want it to be and there is confusion with
h_errno.  If an implementor wants to return in error_num the h_errno
value from a resolver for DNS then they can do that.  What I don't like
I think is to tell those who don't want to use h_errno in this manner
they must use h_errno.  

This is why error_num was defined.  It is the moderate engineering
position which was assumed could satisfy all needs.  

/jim