Jim Blandy <jimb@cygnus.com> writes:
> I must be missing something. The fact that `remove' is the name of a
> C library function is irrelevant --- the namespace of global
> functions/variables doesn't overlap with the namespace of
> svn_delta_edit_fns members. And an editor's `remove' function does do
> almost the same thing as the C library's `remove'.
According to ISO/IEC 9899 (the C standard), header files may indeed
implement library functions as macros by the same name. Text below.
So having a structure member with the same name as a library function
is no good. I retract my suggestion that we rename the
svn_delta_edit_fns_t member.
Hurrah. Gotta love programming languages that give you different
namespaces for clearly distinguishable things, but then add a macro
system which is ignorant of those namespaces, making them unsafe to
take advantage of.
7.1.4 Use of library functions
1 [...] Any function declared in a header may be additionally
implemented as a function-like macro defined in the header, so if a
library function is declared explicitly when its header is included,
one of the techniques shown below can be used to ensure the
declaration is not affected by such a macro. 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. [...]
Received on Sat Oct 21 14:36:21 2006