On Wed, Aug 22, 2012 at 2:05 AM, Marc Espie <[email protected]> wrote:
>> But does this mean we start avoiding local variables that shadow
>> functions? This means that div, pause, time, and many other common
>> names are to be avoided as well, doesn't it?
>
> Well, if you write portable code, you should.
>
> Some of this may be implemented as macros under some OSes ;(
>
> I don't have the C standard with me, but I believe that it doesn't restrict
> very much about this. The only thing I remember for sure is that, unless
> specifically documented differently, functions in the standard must exist
> as functions. They may also exist as macros, and you may have to do
> something like:
> #undef function
> in order to get a pointer to said function...
The problem isn't really the C standard so much as stuff outside of
the standard. The standard makes guarantees about the identifiers and
headers that it specifies:
Any function declared in a header may be additionally implemented
as a function-like macro defined in the header, <...>
...
Any macro definition of a function can be suppressed locally
by enclosing the name of the function in parentheses, because
the name is then not followed by the left parenthesis that
indicates expansion of a macro function name. For the same
syntactic reason, it is permitted to take the address of a
library function even if it is also defined as a macro. The use
of #undef to remove any macro definition will also ensure that
an actual function is referred to.
So, you can use 'div' as the name of a object variable without
concern...if you're in a standard conforming compilation. If you
pulled in a non-standard header or didn't invoke the compiler in
whatever way it takes to be conforming then the rules are off and you
may find a
#define index strchr
macro appearing, for example. POSIX makes a similar guarantee as the
C standard, but again, was the compiler actually invoked in the right
manner to get it? Our base builds, for example, don't.
Philip Guenther
