diff options
author | Jeff King <peff@peff.net> | 2013-08-26 17:57:18 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2013-08-26 21:39:57 -0700 |
commit | 49d6cfa5c2874d78360dc4b16558bb45b5f8e003 (patch) | |
tree | 8a990a49239f56680dd27b069e5e76331fbe3c09 /builtin/help.c | |
parent | do not die when error in config parsing of buf occurs (diff) | |
download | tgif-49d6cfa5c2874d78360dc4b16558bb45b5f8e003.tar.xz |
config: do not use C function names as struct members
According to C99, section 7.1.4:
Any function declared in a header may be additionally
implemented as a function-like macro defined in the
header.
Therefore calling our struct member function pointer "fgetc"
may run afoul of unwanted macro expansion when we call:
char c = cf->fgetc(cf);
This turned out to be a problem on uclibc, which defines
fgetc as a macro and causes compilation failure.
The standard suggests fixing this in a few ways:
1. Using extra parentheses to inhibit the function-like
macro expansion. E.g., "(cf->fgetc)(cf)". This is
undesirable as it's ugly, and each call site needs to
remember to use it (and on systems without the macro,
forgetting will compile just fine).
2. Using #undef (because a conforming implementation must
also be providing fgetc as a function). This is
undesirable because presumably the implementation was
using the macro for a performance benefit, and we are
dropping that optimization.
Instead, we can simply use non-colliding names.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/help.c')
0 files changed, 0 insertions, 0 deletions