From owner-freebsd-arch@FreeBSD.ORG Thu Nov 8 04:05:44 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC02C610; Thu, 8 Nov 2012 04:05:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE498FC15; Thu, 8 Nov 2012 04:05:43 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qA845TMS002866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 15:05:31 +1100 Date: Thu, 8 Nov 2012 15:05:29 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Eitan Adler Subject: Re: removing support for ICC?? In-Reply-To: Message-ID: <20121108145742.J1412@besplex.bde.org> References: <20121107221730.000017c1@unknown> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=I9g936cg c=1 sm=1 a=NhxvjbjkGPYA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=dPA7BKU8QQMA:10 a=jAMlq-imAAAA:8 a=uyavkMrdAAAA:8 a=T_iF5v_dfC5keXuwsoAA:9 a=CjuIK1q_8ugA:10 a=xraHq2XsALYA:10 a=JGX6LFFZUg8A:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: Alexander Leidinger , bde@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 04:05:44 -0000 On Wed, 7 Nov 2012, Eitan Adler wrote: > On 7 November 2012 16:17, Alexander Leidinger wrote: >> On Tue, 6 Nov 2012 15:58:45 -0500 Eitan Adler >> wrote: >> >>> Is there any reason to continue to keep the legacy __INTEL_COMPILER >>> conditional includes around? >> >> Is there a reason to remove them from cdefs.h? There aren't a lot of >> them, they don't obfuscate things, they are not in the way of improving >> things, they don't make the existing stuff harder to read. > > ... > >> cdefs.h is not only used in the kernel, but also in the userland. >> Anything from userland which includes cdefs.h and may also compile on >> other operating systems benefits from keeping this support in cdefs.h. > > I just noticed this ancient stuff in src and decided to clean it up. > > Since it is clearly needed, I'll drop it. Not ancient and not clearly needed, but has a mother. It is certainly unclean (has mounds of style bugs). There is lots of ancient stuff (to support pre-C90 compilers) in cdefs.h. This is really ancient, but more likely needed, since it is for not just 1 compiler. This is mostly cleaner (actually in KNF). Bruce