From owner-freebsd-bugs Thu Mar 13 15:46:39 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA27679 for bugs-outgoing; Thu, 13 Mar 1997 15:46:39 -0800 (PST) Received: from hda.hda.com (ip6-max1-fitch.ziplink.net [199.232.245.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id PAA27673 for ; Thu, 13 Mar 1997 15:46:33 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id RAA07964; Thu, 13 Mar 1997 17:03:49 -0500 From: Peter Dufault Message-Id: <199703132203.RAA07964@hda.hda.com> Subject: Re: bin/2979: Make gcc shut up about extensions when compiling `-pedantic -ansi' In-Reply-To: <7yhgifihds.fsf@base.jnx.com> from Paul Traina at "Mar 13, 97 01:58:23 pm" To: pst@jnx.com (Paul Traina) Date: Thu, 13 Mar 1997 17:03:48 -0500 (EST) Cc: hans@brandinnovators.com, bugs@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > When compiling something which uses statement expressions (e.g > machine/endian.h to get at ntohl()), gcc complains that braces > are not allowed by ANSI C. > > Below is a diff. for the relevant files. Insert `__extension__' > before the expression. > > But this is arguably defeating pedantic. Not only should your code > not use extensions, but the code that you're calling should not. By > placing __extension__ in, you're allowing your code to use nonportable > code. > > I agree with you that this sucks, because all you're really likely to > care about is the portability of YOUR code, not the system code, > but I'm concerned about changing it. I bumped into this exact problem in the last couple of days and removed a -Werror because of it and was glad to see this work around. ntohl on a BSD system can't be considered an extension and is well enough defined that there is no way that the FreeBSD header should generate a warning - that is just going to cause lazy/busy people to do what I did and turn off warnings. In this case this is an appropriate solution. To be totally pedantic, one could add an #if defined(DONT_HIDE_IMPLEMENTATION) around the definition for warnings related to porting issues, or whatever it is that we decide this warning is still needed for. -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936