From owner-freebsd-current Wed May 27 20:48:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA19189 for freebsd-current-outgoing; Wed, 27 May 1998 20:48:11 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA19184 for ; Wed, 27 May 1998 20:48:08 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id NAA09679; Thu, 28 May 1998 13:48:06 +1000 Date: Thu, 28 May 1998 13:48:06 +1000 From: Bruce Evans Message-Id: <199805280348.NAA09679@godzilla.zeta.org.au> To: eivind@yes.no, rnordier@nordier.com Subject: Re: Replacing gcc as the system compiler (was Re: Fix for undefined "__error" and discussion of shared object versioning) Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Have you looked closely at XANDF? I'm seeing two real hurdles (beyond >inertia) in using this as our main compiler: The use of asm() for some >macros in the kernel, and the use of linker sets. What do you think >our chance of working around these are? Linker sets are just asm(). Too bad - I'd like another excuse to kill them. asm() is not sue much in macros, but is used a lot in inline functions. I see inline functions as the main hurdle. Chances of replacing them at reasonable cost are low. >There is also what looks like a bug in handling of NULL - it doesn't >allow the use of ((void *)0) as NULL for function pointers. gcc used to have this bug too. Apparently, the C standard can easily be read as not allowing conversion from (void *)0 to a function pointer. The standard doesn't allow conversion from an object pointer to a function pointer, but (void *)0 is is a null pointer constant and null pointer constants are special. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message