From owner-freebsd-current Thu May 28 13:38:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA21071 for freebsd-current-outgoing; Thu, 28 May 1998 13:38:31 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from mail.camalott.com (root@mail.camalott.com [208.203.140.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA21046 for ; Thu, 28 May 1998 13:38:26 -0700 (PDT) (envelope-from piquan@wcc.net) Received: from detlev.UUCP (tex-135.camalott.com [208.229.74.135] (may be forged)) by mail.camalott.com (8.8.7/8.8.5) with ESMTP id PAA05293; Thu, 28 May 1998 15:23:35 -0500 Received: (from joelh@localhost) by detlev.UUCP (8.8.8/8.8.8) id PAA01692; Thu, 28 May 1998 15:24:32 -0500 (CDT) (envelope-from joelh) Date: Thu, 28 May 1998 15:24:32 -0500 (CDT) Message-Id: <199805282024.PAA01692@detlev.UUCP> To: nate@mt.sri.com CC: rnordier@nordier.com, eivind@yes.no, current@FreeBSD.ORG In-reply-to: <199805281941.NAA20236@mt.sri.com> (message from Nate Williams on Thu, 28 May 1998 13:41:48 -0600) Subject: Re: Fix for undefined "__error" and discussion of shared object versioning From: Joel Ray Holveck Reply-to: joelh@gnu.org References: <199805271551.RAA11565@ceia.nordier.com> <199805281829.NAA01253@detlev.UUCP> <199805281941.NAA20236@mt.sri.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> My own concern would be the amount of code in third-party programs >> that uses gccisms. > Very few programs *should* use gccisms. If they do, they are broke > since they won't build on other OS's compilers. Not necessarily; ifdef's are common: #ifndef __GCC__ #define inline #endif I'm not discussing what should be, I'm discussing what is. We have a good percentage of software from the Linux camps, and many of their software authors wouldn't know a non-portable construct if it walked up and introduced itself in assembly code. >> I guess I don't see why we're looking to change. > Better/faster/less buggy compiler with a much less restrictive Copyright > seems like a win overall to me. I've seen two compile speed tests and one emitted-code benchmark. So far, they indicate that while TenDRA normally compiles faster, its generated code is slower than gcc. I don't know of any bugs in C for gcc 2.7.2.1, and it has a larger user base to find bugs than TenDRA or XANDF. In what ways are these other compilers superior to gcc? (Don't interpret this as belligerence or blind support of gcc; I'm actually asking for information here.) -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message