[FFmpeg-devel] [PATCH] libavcodec/wmavoice.c: local variable pow might mask pow function

Stefan Heinzmann stefan_heinzmann
Mon Jul 26 18:09:43 CEST 2010


M?ns Rullg?rd wrote:

>>>> Specifically, if powf() is defined as a function-like macro in
>>>> <math.h>, its definition would most likely use the pow() function. You
>>>> can expect something like the following:
>>>>
>>>> #define powf(a,b) ((float)pow((double)(a),(double)(b)))
>>>>
>>>> It is entirely legal C99 to have this macro definition in <math.h>,
>>>
>>> No, it is not.  Since 'pow' is not reserved for identifers with local
>>> scope, the header may not use it in any way which might be
>>> incompatible with such use of the identifier in application code.  If
>>> math.h were to implement powf() as a macro, it would have to define
>>> __pow() as an alias for pow() and use this in the macro definition.
>>> Identifiers starting with __ (double underscore) are reserved for any
>>> use, so this would not cause problems for any conforming application
>>> code.
>>
>> Fair enough, could you please point me to clause in the standard
>> that documents this?
>
> As Eli already pointed out, 7.1.3 would be a good place to start.

7.1.3 says this (amongst other things):

-- Each macro name in any of the following subclauses [...] is reserved
   for use as specified if any of its associated headers is included;
   unless explicitly stated otherwise.

I take this to mean the following:

As each function in <math.h> can also be provided as a function-like macro, and pow() is amongst those functions, it means that pow is reserved as soon as <math.h> is included, making it unavailable for use as an identifier to the program. The fact that it is unavailable to the program makes it available for the header, specifically for use in the powf() macro.

At the very least my interpretation seems to be one of several valid interpretations, but there's always a chance that I may have overlooked something. To my defense (not much of a defense), it seems from Axel's description that other people have made the same mistake, even though they work for an irrelevant little company in Seattle.

Quite apart from language (or library) lawyerism, I'm at a loss as to why anyone would want to sail that close to the edge in a code base that is supposed to be portable, particularly when the remedy is so easy and does not appear to have a downside. Is there a hidden point to this seemingly pointless debate, or is it just owing to lust for dogmatic dispute?

--
Stefan Heinzmann

-- 
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.  
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl



More information about the ffmpeg-devel mailing list