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 <math.h>" 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/
