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

[Alex Converse]

2010/7/26 M?ns Rullg?rd <mans at mansr.com>:
> "Stefan Heinzmann" <stefan_heinzmann at gmx.de> writes:
>
>> 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.
>
> Function-like macros don't conflict with variables. ?Functions in C
> have file scope, and file-scope identifier with those names are
> clearly reserved by including the header.
>

#include <stdio.h>
#include <math.h>
#undef powf
#define powf(x,y) ((float)pow((float)(x),(float)(y)))

int main() {
	float pow;
	pow = powf(2, 3);
	printf("%f\n", pow);
	return 0;
}

scope.c: In function `main':
scope.c:8: error: called object `pow' is not a function

>> 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?
>
> We don't make changes just because someone says so. ?We need a reason,
> no matter how small the change.
>

It could be argued that not conflicting with these names increases readability.