From owner-freebsd-hackers Thu Mar 20 11:01:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA00344 for hackers-outgoing; Thu, 20 Mar 1997 11:01:42 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id LAA00338 for ; Thu, 20 Mar 1997 11:01:38 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA14080; Thu, 20 Mar 1997 11:49:59 -0700 From: Terry Lambert Message-Id: <199703201849.LAA14080@phaeton.artisoft.com> Subject: Re: Barb problem, FOUND To: imp@village.org (Warner Losh) Date: Thu, 20 Mar 1997 11:49:59 -0700 (MST) Cc: james@wgold.demon.co.uk, hackers@FreeBSD.ORG In-Reply-To: from "Warner Losh" at Mar 20, 97 08:17:28 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > : Just because a particular compiler is full of bugs doesn't mean that a > : construct allowed by the language spec is dubious. No way. > > I misspoke myself. There are several compilers that don't handle this > construct correctly. They generally don't whine about it, but they > generally do generate horrible code for this case. We saw a few years > ago that by removing the inline virtuals we had binaries that were > 500k! smaller. We also found with OI that lots of compilers had > subtle bugs with inline virtuals. > > Given all the problems that multiple compilers have implementing it > effectively, I think that it is as least unwise to use the construct. > In my book, that makes it dubious, but others will have a different > opinion. I remember when people were applying the same logic to dynamic scoping of stack variables: if( foo) { int my_dynamic_i; ... } Use of the register keyword on Lattice (later SASC) compilers: fum() { register int a, b, c, d, e, f; /* all the registers...*/ register int q; /* XXX reuses register 'a'!!!*/ } And use of bit fields, unsigned values. and enumerated types (which didn't work in so many odd ways that it's not worth going into). Oh yeah: don't use sbrk() because you can't brk() back to the OS... 8-P. The argument is without merit: if a compiler is buggy, it should be fixed, or the vendor should be forced out of business by word of mouth. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.