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

[Måns Rullgård]

Alex Converse <alex.converse at gmail.com> writes:

> 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

This error is entirely of your own doing.  _You_ defined a macro
calling 'pow' as a function, then defined 'pow' to be something else.
You are allowed to have locally scoped identifiers shadow things
declared in an outer scope, but if you do that, you obviously cannot
_also_ use the outer definition.

A proper header file should never cause an error from shadowing an
identifier which is never used directly.

>>> 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.

That is an argument I could agree with.  However, it was not made.

-- 
M?ns Rullg?rd
mans at mansr.com