summaryrefslogtreecommitdiff
path: root/revision.c
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2013-08-26 17:57:18 -0400
committerJunio C Hamano <gitster@pobox.com>2013-08-26 21:39:57 -0700
commit49d6cfa5c2874d78360dc4b16558bb45b5f8e003 (patch)
tree8a990a49239f56680dd27b069e5e76331fbe3c09 /revision.c
parentb2dc09455a9ed5521c2e84fc67d8dacf2c28c39f (diff)
downloadgit-49d6cfa5c2874d78360dc4b16558bb45b5f8e003.tar.gz
config: do not use C function names as struct membershv/config-from-blob
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 'revision.c')
0 files changed, 0 insertions, 0 deletions