Created by Bert Driehuis (driehuis@playbeing.org) 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 (driehuis@playbeing.org) 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 (wtc@netscape.com) 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 (wtc@netscape.com) 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.

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

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

marking as fixed.

VERIFIED due to no changes in over a year