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.