From owner-freebsd-current Fri May 29 16:31:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA29745 for freebsd-current-outgoing; Fri, 29 May 1998 16:31:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA29722 for ; Fri, 29 May 1998 16:31:22 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA22721; Fri, 29 May 1998 16:31:10 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd022646; Fri May 29 16:31:04 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id QAA23999; Fri, 29 May 1998 16:30:56 -0700 (MST) From: Terry Lambert Message-Id: <199805292330.QAA23999@usr05.primenet.com> Subject: Re: Fix for undefined "__error" and discussion of shared object versioning To: mike@smith.net.au (Mike Smith) Date: Fri, 29 May 1998 23:30:55 +0000 (GMT) Cc: tlambert@primenet.com, joelh@gnu.org, nate@mt.sri.com, rnordier@nordier.com, eivind@yes.no, current@FreeBSD.ORG In-Reply-To: <199805292157.OAA01107@dingo.cdrom.com> from "Mike Smith" at May 29, 98 02:57:04 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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