Subject: (IPng 7194) Re: sockaddr_storage nit

From: Mukesh Kacker <[email-masked]>
Date: Wed, 17 Feb 1999 22:52:24 -0800 (PST)

> Subject: (IPng 7185) sockaddr_storage nit

..Not that thing again :-)

Craig, you are right that when we discussed it on emails the field
was called ss_family, I am not sure when it got the leading underscores.

However, if now it is tough to change, there is another way to look at things.

You wrote:

>  The entire
> point of having those fields in the structure is for the basic sockaddr
> preamble fields to be accessable without a cast. Therefore, they should not be
> "hidden."
>

The point of having those fields was also to affect how in its implementation
the alignment issues get handled. Note that the structure is to get
large enough aligned storage for socket address data structures. We already
have the old "struct sockaddr" which can be used to a access what
you call the "preamble fields"

This you can declare
	struct sockaddr_storage ss;
	struct sockaddr *sassp = (struct sockaddr *) &ss;

Then you can access the preamble fields through sockaddr
(e.g. above , sassp->sa_family) and have portable code.
(And to correct the terms, there is no "interoperabilty" issue here...
...only a portability issue).
I must admit I don't have strong feelings against using type casts
in general. In Socket API you have to use them implicitly in parameters
to functions in any case (i.e sockaddr * arguments are usually sockaddr_in
or sockaddr_in6 etc).

Another unexpected benefit might be that the we save the entire ss_ namespace
for applications which in the usual Posix/TOG spec methodology is taken
away from applications because it is a field name prefix and I hate that. :-)

- Mukesh Kacker
  Internet Engineering
  Solaris Software
  Sun Microsystems Inc
  +1-650-786-5156
--------------------------------------------------------------------
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: Craig Metz <[email-masked]>
Date: Thu, 18 Feb 1999 02:25:59 -0500

>was called ss_family, I am not sure when it got the leading underscores.

  Nor am I. A *lot* of proposals went back and forth in those discussions, and
I suspect both of us were sick and tired of tweaking it...

>However, if now it is tough to change, there is another way to look at things.

  Jim declared that he isn't changing the spec.

>> preamble fields to be accessable without a cast. Therefore, they should not 
>> "hidden."

>you call the "preamble fields"

  My original statement was correct as made. The entire point of having those
fields -- which are there primarily because I kept pushing for them -- was to
be able to access the sa_len and sa_family equivalents without the need for
a cast, just like you can with any other struct sockaddr_foo.

  If there is no accessability for the preamble fields, then why do we have
them at all (and the somewhat messy definition that results)? The fields should
either be there as first-class members or not be there at all. The current spec
puts them somewhere in between.

>in general. 

  One of the original motivations behind the sockaddr_union was that lots of
type casts (and, IMO worse, aliases of different types) create less readable
code and more potential for programmer errors that the compiler frequently
can't catch.

>away from applications because it is a field name prefix and I hate that. :-)

  Would this really take away the global ss_ namespace? That's icky.

									-Craig

---

From: Jim Bound <[email-masked]>
Date: Thu, 18 Feb 1999 11:54:29 -0500

Craig,

I did not declare I would not change the spec.  I declared I would not
change the spec without a lot of implementors telling me they can't live
with this.  As Mukesh pointed out it is a portability issue you raise
and I just want to hear from all the implementors on this because the
spec completed last call and is getting a new RFC at this time.

So I would have to hear from Sun, Compaq (I will keep myself out of this
and let my colleagues at Compaq respond), HP, IBM, Mentat, et al 
"implementors" and the other non-Vendor OS's implementors to change 
this spec and recall the IETF process updating the spec as we speak.

Also you were part of the folks to help define 3.10 and I recorded that
in tact.  The __SS... were put into to avoid name space pollution for
sockaddr_storage as I recall.  I think that still stands.

But there are work arounds for portability folks can do as Mukesh
pointed out.  If those will work I think that is better for IPv6 is if
we leave the spec in tact for now.  It has been worked on for so long we
got to put it to bed.

Also I believe XNET specs can update the spec and possibly generate
later another Informational RFC called XNET Version of the API if it
cannot be made publicly.

To reiterate it is not that I will not change the spec it is I will not
change the spec lightly.

Also I want to add that many users of UNIX require the UNIX 95 and soon
the UNIX 98 standards.  If the public domain of UNIX does not support
those they will not be used by those customers.  But maybe that is OK.

/jim