summaryrefslogtreecommitdiff
path: root/Documentation/RelNotes/1.7.9.txt
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2013-08-26 17:57:18 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2013-08-26 21:39:57 -0700
commit49d6cfa5c2874d78360dc4b16558bb45b5f8e003 (patch)
tree8a990a49239f56680dd27b069e5e76331fbe3c09 /Documentation/RelNotes/1.7.9.txt
parentdo not die when error in config parsing of buf occurs (diff)
downloadtgif-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 'Documentation/RelNotes/1.7.9.txt')
0 files changed, 0 insertions, 0 deletions