From owner-freebsd-mozilla Thu Jan 18 0:38:13 2001 Delivered-To: freebsd-mozilla@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 67DC137B400; Thu, 18 Jan 2001 00:37:52 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id BAA21519; Thu, 18 Jan 2001 01:35:10 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAAXaaG_P; Thu Jan 18 01:35:04 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id BAA01684; Thu, 18 Jan 2001 01:37:42 -0700 (MST) From: Terry Lambert Message-Id: <200101180837.BAA01684@usr08.primenet.com> Subject: Re: Mozilla & PSM -- the final word To: nsayer@quack.kfu.com Date: Thu, 18 Jan 2001 08:37:32 +0000 (GMT) Cc: freebsd-ports@FreeBSD.ORG, freebsd-mozilla@FreeBSD.ORG, reg@FreeBSD.ORG In-Reply-To: <200101170548.f0H5mKW17658@morpheus.kfu.com> from "nsayer@quack.kfu.com" at Jan 16, 2001 09:48:20 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-mozilla@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Applying this patch to work/mozilla/nsprpub/pr/src/misc/prnetdb.c fixes > the problem that I hacked around with the #if 0 in my previous e-mails. > This patch is also now in Mozilla bug 65549, but until they commit it > it should probably become part of the mozilla port. Without it, the > psm doesn't work on BSD. [ ... bzero of in_addr ... ] This is a common Linux-ism, which appears to sometimes work on Solaris. I don't know if they are zeroing their stacks when allocating auto variables, or what, but the orginal SLPv1 code, which was written on Linux, and some of the LDAP libraries that people contributed, had the same problem everywhere. Really, this is code that won't work, except on IPv4, and then only on platforms that zap the options part of the struct, or just don't use common code for the bind() and the setsockopt() calls. It might be a good idea to compile a list of these things to use in code audits; unfortunately, this is the only one that jumps out as a Linux-ism right now. I know that SunOS 4.x's native compiler had a nice problem with a stack pop-order bug, where if you did: some_type_t *some_pointer; ... some_pointer = function( some_pointer); It would do the assign and _then_ the pop, if some_pointer was in a register; this was a problem with the Berkeley C compiler, and was called "the Berkeley pop order bug" everywhere that I knew of peope who knew it happened. It played hell with Motif, which did this type of pointer assignment everyhwere it could, for no good reason. One compiler I knew (this is just a Windows issue) would re-use registers for variables declared inside a statement (e.g. following the "{" in a "for" or "if" or other statement that wan't actually a function block; Lattice C had this problem. Microsoft C would do the wrong thing for: foo() { char *p = "Hello World!" + 6; puts( p); puts( p - 6); } because it failed to emit a pseudo-quad for p - 6, and "lost" "Hello " from the data segment. I've also seen a number of problems with unions, bitfields, structure packing, and unalkigned access. Except for unaligned access fixups, which some OS's do automatically, eating the overhead of a fault + fixup, instead of faulting and coring the offensive program, most of these aren't issues if you assume "all the world is GCC", which a lot of people unfortunately do, these days. I guess the worst modern problems are all Linux assumptions that aren't valid elsewhere... 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mozilla" in the body of the message