From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1753 invoked by alias); 1 May 2014 23:46:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 1735 invoked by uid 89); 1 May 2014 23:46:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 3 recipients X-HELO: shepard.synsport.net Received: from mail.synsport.com (HELO shepard.synsport.net) (208.69.230.148) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 01 May 2014 23:46:14 +0000 Received: from [192.168.0.20] (unknown [130.255.19.191]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id B3A07435AC; Thu, 1 May 2014 18:45:49 -0500 (CDT) Message-ID: <5362DC9B.8090709@marino.st> Date: Thu, 01 May 2014 23:46:00 -0000 From: John Marino User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Joseph S. Myers" CC: gcc-patches@gcc.gnu.org, Jonathan Wakely , Gerald Pfeifer , manu@gcc.gnu.org, "Eric Botcazou (gnu.org)" Subject: Re: Contributing new gcc targets: i386-*-dragonfly and x86-64-*-dragonfly References: <5352D100.9040108@marino.st> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00035.txt.bz2 On 5/2/2014 01:03, Joseph S. Myers wrote: > The include of from seems risky, given that > that's a POSIX header that typically defines various types ISO C does not > permit to be defined in (ISO C does not have any general *_t > namespace reservation, unlike POSIX). > > Have you verified that if you include with -std=c90 / -std=c99 > / -std=c11, the resulting definitions (compiler and preprocessor) are all > ones permitted by the relevant C standard version to be provided by > ? You bring up some interesting points. I haven't specific tested anything like that, but DragonFly has been using this modification for years - since gcc 4.6 at least. It is even in the primary base compiler: http://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/contrib/gcc-4.7/gcc/ginclude/stddef.h So given the track record (building itself, building base, building 21,000 software ports) over a couple of years I think any issues this could have caused would have been seen and identified by now. > > (I don't know what the FreeBSD defines, but it at least > seems possible from the name that it is only defining things in the > implementation namespace, with the public being what then > includes and does "typedef __foo_t foo_t;" or similar to > provide the public POSIX types that aren't in ISO C.) Here are the headers in question: http://grok.dragonflybsd.org/xref/freebsd/sys/sys/_types.h http://grok.dragonflybsd.org/xref/dragonfly/sys/sys/types.h Thanks, John