Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <200406151753.i5FHre8V029196@smtp-out2.xs4all.nl> From: "Johnny Willemsen" To: Subject: RE: log2 as function not as macro Date: Tue, 15 Jun 2004 19:53:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, > And the answer there will probably be that if your code depends on whether > this function is a macro or a real function then your code is not valid C. > The C language spec specifically says that implementations are free to > provide library functions as macros as well as functions. See > > http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html > > and in particular the lines that say "The following shall be declared as > functions and may also be defined as macros. Function prototypes shall be > provided." > > So if your code has a problem with that, your code does not comply with > the C language spec. > > cheers, > DaveK Dave, To be fair, the original poster described the exact problem: > log2 as macro is hard to use in projects that also define a log2 function. I'm not sure how your link can be reconciled with this, but at a guess, projects that define a log2() function are expected to follow "#include " with "#undef log2". Yes, you are correct, we do this now in this way. Cygwin is the only environment for which we have to do this and I just don't like it. It means we have to include math.h in a header file where we don't need it. A change to a function would make life easier. Johnny -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/