Hi Paul, Thanks again. Sorry for the delay, I was one day off. Except the patch supplied to Jonathan Lennox, I was able to apply them all. Will I get the latest sources (including all previously sent patches) when I run: git clone https://github.com/eggert/tz.git? Anyhow, I created a simple example where I found that gcc does not recognize any mismatch in int types (between declaration and definition) with only const qualifiers are added. Also note the strange error regarding the [const] char * mismatch. See example below. Just try to compile with gcc -Wall -Wextra -o <output> <input-c-file-as-copied from this email>. If you find this gcc behavior odd too, I will check whether I can file this to the gcc/gnu.org folks. #include <stdio.h> static void f(const int i); static void g(int i); static void h(const char *s); int main(void) { f(3); g(4); h("A joke"); return 0; } static void f(int i) { printf("f-Input is: %d\n", i); } static void g(const int i) { printf("g-Input is: %d\n", i); } static void h(char *s) { printf("h-Input is: %s\n", s); } Regards, Kees -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Wednesday, July 29, 2015 03:46 To: Kees Dekker Cc: Time zone mailing list Subject: Re: [tz] suggestions for potential code improvements? Kees Dekker wrote:
Both date.c, zdump.c, zic.c contain a number of static functions where the declaration differs from the implementation. This applies to: Date.c: wildinput(), oops(), display(), timeout(), iffy(). Zdump.c: yeartot() Zic.c: dolink(),itsdir(),inrule(),inzone(),inzcont().
Thanks, should be fixed in the attached proposed patch (installed on Github).
I also found that Visual Studio is the compiler that reports (line numbers corrected to match with your sources):
1>w:\logic\tz\zdump.c(970): error C4295: 'wday_name' : array is too small to include a terminating null character 1>w:\logic\tz\zdump.c(974): error C4295: 'mon_name' : array is too small to include a terminating null character
As mentioned earlier there is no bug there. the compiler is merely complaining about style, and pacifying the compiler will require making the code a little larger at run-time; so let's leave the code alone.
Some other remarks of the previous email (like gmtime_r() does not exist on Windows, and regarding conversion errors from size_t to int) also exist in the previously mentioned 3 source files, but I first like to know your thoughts regarding the mail below before I will provide additional feedback.
For warnings about implicit conversions I wouldn't worry unless there is a real bug. I don't see why MS-Windows' lack of support for gmtime_r is a problem: tzcode supplies its own gmtime_r implementation and this implementation should work.