From owner-freebsd-current Mon Dec 4 10:57:48 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA23386 for current-outgoing; Mon, 4 Dec 1995 10:57:48 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA23381 for ; Mon, 4 Dec 1995 10:57:45 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA04032; Mon, 4 Dec 1995 11:53:45 -0700 From: Terry Lambert Message-Id: <199512041853.LAA04032@phaeton.artisoft.com> Subject: Re: changes in -current..TEST please To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 4 Dec 1995 11:53:45 -0700 (MST) Cc: terry@lambert.org, imb@scgt.oz.au, julian@ref.tfs.com, current@FreeBSD.org In-Reply-To: <281.818071658@critter.tfs.com> from "Poul-Henning Kamp" at Dec 4, 95 10:07:38 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1589 Sender: owner-current@FreeBSD.org Precedence: bulk > Terry, read your manuals again before you talk about things you don't > know too much, and certainly not enough, about. I think: #define MAKE_SET(set, sym, type) \ asm(".stabs \"_" #set "\", " #type ", 0, 0, _" #sym) Is silly. I think there should be a C accessable __STABS() or similar mechanism so the compiler cn track it, if it insists on sticking its fat, warty nose into my business sufficiently to screw it up. At worst, it should not remove "dead" code added with asm(). At best, the ability to do this is a language feature, either directly, or by way of the compiler being able to generate linker directives in the object code it produces. Either way, a "dead-code" optimization should not remove the code. It is not dead, since the linker will use it to build a structure. Dead code optimization should cause fatal errors instead of diking things out, forcing the programmer to fix the offending code. That is, it is an unfeature for lazy programmers. Whatever feature of C++ that prevents "dead code 'optimization'" killing constructors and destructors should be employed to prevent this use of the underlying mechanism on which they are implemented from being similarly 'optimized'. Luckily, we do not have to face this problem, since GCC 2.7.1 is known to generate bogus code for optimization levels above 2 anyway, so we will never encounter an optimization of this type in nature. [that was irony, if you missed it] Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.