On Jul 24, 2015, at 12:10 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Kees Dekker wrote:
Hi Paul,
I tried to compile the code (Visual Studio 2013 as first try, the other platforms will follow later), but I found some (minor) things:
1. The implementation of difftime() is specified with const arguments, while none of the referred places use these const qualifiers (e.g. private.h:368). ...
Const mismatches: 3. There are (static) prototype mismatches between strftime.c:99 and the implementation of _fmt (arguments 2 and 4 have additional const in definition) 4. idem for strftime.c:98 and the implementation of _conv() at line 572 (arguments 1, 2, 3 and 4 have additional const qualifiers) 5. idem for strftime.c:97 and the implementation of _add() at line 580 (arguments 3 and 6 are different from declaration) I don't really prefer one or other, but usually a compiler may optimize const qualified code somewhat better.
That shouldn't matter. If the argument to a function is declared 'const', the 'const' attribute matters only in the body of the function; it is irrelevant to callers. This has been true ever since C was standardized in C89. No decent compiler should generate different code because of the extra 'const's here.
If I read Kees’s comments correctly, he's talking about mismatches between declaration and definition. That’s a different issue; the two should match. You’re correct that a caller can pass a non-const input into a const argument, that is of course legal, but that doesn’t appear to be what the complaint is about. paul