235 - PRNetAddr doesn't match sockaddr_in

Status: VERIFIED FIXED

(NSPR :: NSPR, defect, P3)

Description

[Bert Driehuis]

Created by Bert Driehuis ([e-mail]) on Wednesday, April 15, 1998 4:01:59 PM PDT
Additional Details :
Building Mozilla 1998-04-08 fails on BSD/OS 3.0. On
investigation, the definition of PRNetAddr (which is cast
into a sockaddr_in in ns/nsprpub/src/md/unix/unix.c in the
MD_connect routine) turns out to use a short in host order
for the sin_family field. BSD/OS 3.0 (and I'd imagine all
4.4lite2 derived unixes, but I haven't checked) define this
field as
	u_char sa_len;
	u_char sa_family;
which happens to be byte-swapped w.r.t. the assumptions in
ns/nsprpub/include/prio.h, where these two bytes are
addressed as one PRUint16.

This needs to be addressed, probably in
ns/nsprpub/src/md/unix/unix.c, by filling in a sockaddr_in
from the PRNetAddr structure, before performing the connect.

I haven't provided a fix, since I'm not positive about the
proper way of fixing it. I'll see if I can come up with a
solution that works with BSD/OS 3.0 without obviously
breaking ports on which casting to sockaddr_in works.
Updated by Bert Driehuis ([e-mail]) on Wednesday, April 15, 1998 4:35:06 PM PDT
Additional Details :
This patch gets the BSDI 3.0 version working:

*** nsprpub/pr/src/md/unix/unix.c.dist  Thu Apr  9 02:52:30 1998
--- nsprpub/pr/src/md/unix/unix.c       Thu Apr 16 01:21:47 1998
***************
*** 1062,1065 ****
--- 1062,1072 ----
        PRThread *me = _PR_MD_CURRENT_THREAD();
      PRInt32 osfd = fd->secret->md.osfd;
+ #ifdef __bsdi__
+       struct sockaddr the_addr;
+       the_addr = *((struct sockaddr *)addr);
+       the_addr.sa_len = sizeof(the_addr);
+       the_addr.sa_family = addr->inet.family;
+       addr = (PRNetAddr *) &the_addr;
+ #endif
  #ifdef IRIX
  extern PRInt32 _MD_irix_connect(
***************
*** 2317,2321 ****
                osflags |= O_TRUNC;
        if (flags & PR_SYNC) {
! #if defined(FREEBSD)
                osflags |= O_FSYNC;
  #else
--- 2324,2328 ----
                osflags |= O_TRUNC;
        if (flags & PR_SYNC) {
! #if defined(FREEBSD) || defined(__bsdi__)
                osflags |= O_FSYNC;
  #else

(the FreeBSD/BSDI fix could probably have been avoided by conditionalizing on BS
D44LITE2 or something like that, that would help NetBSD as well, I guess).

Are there any systems that Mozilla runs on that don't define sa_len?

I could unfortunately not update my report using Mozilla 1998-04-08 because of
apparent JavaScript lossage ("try again: you didn't specify a short
description). Fortunately, 4.04 works just fine :-)
Updated by Wan-Teh Chang ([e-mail]) on Wednesday, May 6, 1998 8:02:09 PM PDT
Additional Details :
Assigned bug to myself.

The O_FSYNC bug has been fixed.

I will look at the sockaddr_in.sa_len bug.
Updated by Wan-Teh Chang ([e-mail]) on Thursday, May 7, 1998 8:56:24 AM PDT
Additional Details :
I just fixed the sockaddr_in.sa_len problem in
mozilla/nsprpub/pr/include/md/_bsdi.h, revision
3.2, in conjunction with a prior fix to
mozilla/nsprpub/pr/src/md/unix.c.

I define the macro _PR_HAVE_SOCKADDR_LEN in _bsdi.h.
(This macro is also defined for _aix.h, _freebsd.h,
and _rhapsody.h, indicating their BSD4.4 heritage.)
The code in unix.c checks the _PR_HAVE_SOCKADDR_LEN
macro and does the appropriate things.

I ran a few socket tests (in mozilla/nsprpub/pr/tests)
on our BSD/OS 2.1 and 3.0 machines and they all pased.

Closed the bug.

PS: To answer your question, yes, there are platforms
that do not have a length field in their sockaddr, e.g.,
Solaris.

Comment 1

[Terry Weissman]

NSPR now has its own Bugzilla product.  Moving this bug to the NSPR product.

Comment 2

[Jesse Ruderman]

these bugs are closed but have no resolution.  reopening...

Comment 3

[Jesse Ruderman]

marking as fixed.

Comment 4

[Brant Gurganus]

VERIFIED due to no changes in over a year