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

[Stefan Heinzmann]

M?ns Rullg?rd wrote:
> "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.

You seem to be referring to another clause in the same paragraph:

-- Each identifier with file scope listed in any of the following
   subclauses [...] is reserved for use as a macro name and as an
   identifier with file scope in the same name space if any of its
   associated headers is included.

Note how this clause specifies explicitly what the identifier is reserved *for* (and by implication the other usages are allowed). In the clause I cited earlier this isn't so, and to me it indicates that the earlier clause reserves macro names in the header for *any* use by the program, in contrast to the latter clause that applies to (non-macro) identifiers with file scope.

In short, I don't see why my interpretation shouldn't be valid according to the standard, even though I readily admit that other interpretations may be equally valid.

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

I was under the impression that it had been given, but there may be some debate about what constitutes a valid reason. At least, the innuendo that Axel may be trolling was unwarranted IMHO.

--
Stefan Heinzmann

-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail