[tz] suggestions for potential code improvements?

Kees Dekker Kees.Dekker at infor.com
Thu Jul 30 15:06:28 UTC 2015


Addition:

Localtime.c will have a gmtime_r() but of the system does not recognize gmtime_r(), there is also no prototype. So both localtime.c and zdump.c will suffer from it.
And I would expect only one implementation (in localtime.c), not another one in zdump.c...not sure whether I'm not making a mistake.

Regards,
Kees

-----Original Message-----
From: Kees Dekker 
Sent: Thursday, July 30, 2015 16:42
To: 'Paul Eggert'
Cc: 'Time zone mailing list'
Subject: RE: [tz] suggestions for potential code improvements?

Hi Paul,

Remarks on date.c:
The definitions of static functions oops() and iffy() do not have a declaration (raising e.g. 'oops' undefined; assuming extern returning int in Visual Studio (and probably other compilers). Can you please add two prototypes for these static functions?

BTW. I think the two files that were not correctly patched are the Makefile and date.c. So my comments on date.c may be related to an outdated version.

Remarks for zdump.c:
You said that tzcode supplies its own gmtime_r(). Do you mean the onze in zdump.c itself? That one is only supplied if HAVE_LOCALTIME_R was not set/defined.

Remarks for zic.c:
There are still some inconsistent prototypes: inleap(),inlink(),rulesub(),outzone(),addtt(),yearistype(),byword(), oadd(),tadd(),rpytime(),newabbr(). If you can make them consistent (declaration & definition) it would be great.

Regards,
Kees

-----Original Message-----
From: Kees Dekker 
Sent: Thursday, July 30, 2015 15:19
To: 'Paul Eggert'
Cc: Time zone mailing list
Subject: RE: [tz] suggestions for potential code improvements?

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 at 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.


More information about the tz mailing list