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

[Måns Rullgård]

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

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

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