Date: Sun, 31 Aug 2003 21:36:53 +0200 From: Erik Trulsson <ertr1013@student.uu.se> To: "M. Warner Losh" <imp@bsdimp.com> Cc: wollman@khavrinen.lcs.mit.edu Subject: Re: POSIX_C_SOURCE Message-ID: <20030831193653.GA45277@falcon.midgard.homeip.net> In-Reply-To: <20030831.113543.12223209.imp@bsdimp.com> References: <20030830161813.GA28890@twisted.net> <200308301649.h7UGnF5H042361@khavrinen.lcs.mit.edu> <20030830171343.GA33800@falcon.midgard.homeip.net> <20030831.113543.12223209.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 31, 2003 at 11:35:43AM -0600, M. Warner Losh wrote: > In message: <20030830171343.GA33800@falcon.midgard.homeip.net> > Erik Trulsson <ertr1013@student.uu.se> writes: > : /* Deal with IEEE Std. 1003.1-1990, in which _POSIX_C_SOURCE == 1. */ > : #if _POSIX_C_SOURCE == 1 > : #undef _POSIX_C_SOURCE /* Probably illegal, but beyond caring now. */ > : @@ -280,6 +282,8 @@ > : #undef _POSIX_C_SOURCE > : #define _POSIX_C_SOURCE 199209 > : #endif > > That's 100% legal and should *NOT* produce a warning. Garrett is > right. It is 100% legal, yes. Nobody has said differently. I disagree that it should not produce a warning[1], but it *does* *not* *matter* whether a warning should or should not be produced. Gcc *does* give a warning on that code, and those warnings can be quite annoying. Applying the patch I posted will stop gcc from issuing the annoying warnings and has no other effects. It might not be the "correct" way of fixing the problem (the problem being that gcc issues lots of annoying and useless warnings on the code in cdefs.h when compiling perfectly fine programs) but I haven't seen anybody propose any other solution that is "better". Is there some *actual* problem with the patch I posted which would prevent it from being applied to RELENG_4 ? (Other than the objection of "it shouldn't be neccessary, gcc shouldn't give a warning on that code" which is irrelevant since gcc does issue a warning.) The patch is: a) Perfectly legal C b) Has no harmful sideeffects c) Solves a problem (getting rid of annoying, useless, warnings) d) Is arguably better style than the previous code (this is most certainly arguable, since we are essentially arguing about it right now, but since several different, reasonable, opinions obviously exist it is a fairly good indication that there is no "right" way to do this and my points a)-c) above should be given more weight than what somebody thinks the "right" programming style is. There are three other possible "solutions", each of which I consider to be much worse: a) Do nothing. Accept that gcc will spew out lots of annoying, useless warnings when compiling several ports. b) Change the compiler flags used by all the affected ports, so that they don't have the warning enabled. (I.e. remove -Wundef from the flags used by the affected ports.) c) Change the documented behaviour of gcc so it doesn't issue a warning for this case. Of these b) is the only option that I would consider to be somewhat acceptable and that would probably entail a lot of work. [1] I think that relying on the fact that undefined preprocessor constants is replaced by the value 0 in preprocessor expressions, although legal, is lousy programming practice and should be discouraged. Gcc certainly should issue that warning when invoked with -Wundef since that is what that option is documented to do. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030831193653.GA45277>