Date: Thu, 18 Jan 2001 08:37:32 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nsayer@quack.kfu.com Cc: freebsd-ports@FreeBSD.ORG, freebsd-mozilla@FreeBSD.ORG, reg@FreeBSD.ORG Subject: Re: Mozilla & PSM -- the final word Message-ID: <200101180837.BAA01684@usr08.primenet.com> In-Reply-To: <200101170548.f0H5mKW17658@morpheus.kfu.com> from "nsayer@quack.kfu.com" at Jan 16, 2001 09:48:20 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101180837.BAA01684>