Date: Fri, 29 May 1998 23:30:55 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: tlambert@primenet.com, joelh@gnu.org, nate@mt.sri.com, rnordier@nordier.com, eivind@yes.no, current@FreeBSD.ORG Subject: Re: Fix for undefined "__error" and discussion of shared object versioning Message-ID: <199805292330.QAA23999@usr05.primenet.com> In-Reply-To: <199805292157.OAA01107@dingo.cdrom.com> from "Mike Smith" at May 29, 98 02:57:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > If the plan is to "make it work anyway", how do you propose the common > > Linux programming error where they fail to zero sockarr_in contents > > before partially filling in values and using them? > > Fix the (broken) code in the kernel that depends on zero terminators in > "magic" locations. I think that Linux works not because these "magic" places are handled "correctly", but because it zeros stack page allocations for "security reasons", and simply lucks out that the call graph doesn't descend then ascend leaving crap behind. >From my reading of the use of the structure contents, it's perfectly valid to fill out other pieces of teh structure with non-zero values and then expect the kernel to interpret the non-zero values as significant. The problem is in the default value of zero being significant, AND in the default value from the stack being non-zero, but not ALSO significant. When I ported the sample implementation of the Service Location Protocol code from Sun Microsystems, I had to de-Linux the type type declarations, then memset( &x, 0, sizeof(struct sockaddr_in)); all over the place. While we are on the subject of portability problems, doesn't anyone else find it annoying that memcpy() is not guaranteed to work on overlapping memory ranges, yet we are migrating bcopy() to memcpy() as time goes on? Grrrr... 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-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805292330.QAA23999>