Subject: Re: cleaning up the rest of dtom()
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: enami tsugutomo <enami@ba2.so-net.or.jp>
List: tech-kern
Date: 06/25/1997 07:53:59
Jason Thorpe <thorpej@nas.nasa.gov> writes:

> On 24 Jun 1997 15:47:39 +0900 
>  enami tsugutomo <enami@cv.sony.co.jp> wrote:
> 
>  > > + 	if (nam->m_len > sizeof(struct sockaddr_un))
>  > > + 		return (EINVAL);
>  > >   	if (unp->unp_vnode != 0)
>  > >   		return (EINVAL);
>  > >   	NDINIT(&nd, CREATE, FOLLOW | LOCKPARENT, UIO_SYSSPACE,
>  > 
>  > If we check length of socket name strictly, the XXX marked test just
>  > after this NDINIT line (which tests special case that sun_path is 105
>  > byte + nul in case of NetBSD/i386) can be eliminated, can't it?  Or,
>  > supposed to be done in next step?
> 
> Well, the first check would definitely ensure that the path name was
> 103 bytes + nul... (sun_path is declared as "char sun_path[104]").

Yes, so, I want to say that following test (which comes after NDINIT
above example) now becomes always false...

	if (nam->m_data + nam->m_len == &nam->m_dat[MLEN]) {	/* XXX */

Or is there any arch on which mbuf length is less than 128 byte?  Hmm,
or is there arch on which sizeof sockaddr_un becomes 108 byte by some
alignment matter...?

# btw, the first check ensures path name is 104 byte (with or without
# nul).  105 byte + nul (in other words, address length is 108 byte)
# is only the special case which requires to include nul in the
# address.  (when mbuf is 128byte)

enami.