[tz] [PATCH] Support building zic.exe and zdump.exe natively on Windows with Visual Studio nmake.

Manuela Friedrich Manuela.Friedrich at actian.com
Wed Feb 7 17:26:08 UTC 2018

Hello Paul,

I have removed the code to use Windows native localtime() etc functions but that caused a crash in zdump.
In zdump localtime_r() was calling localtime() but it crashed after the return from localtime because there was no prototype for localtime and thus localtime_r did receive an integer instead of struct tm*.
I added the prototype to private.h.

With regards to have tzloadbody() check for a dos drive specifier I found zdump was not showing the transition times when I omitted the change.
We need to run zdump -v with a full path to the time zone file because the time zone files are located in our product installation and customers decide where they install our software.
So we do not know TZDIR at compile time and the code that prepends TZDIR to the path actually corrupts the full path.
Therefore it is crucial for us to have the dos specifier check in tzloadbody().
This change won’t affect the behaviour on Unix and using a full path works fine on Unix.

I’d like to suggest the following patch.

localtime.c | 4 ++++
private.h   | 2 ++
2 files changed, 6 insertions(+)

diff --git a/localtime.c b/localtime.c
index 6f5aa76..18b6412 100644
--- a/localtime.c
+++ b/localtime.c
@@ -401,6 +401,10 @@ tzloadbody(char const *name, struct state *sp, bool doextend,
               if (name[0] == ':')
               doaccess = name[0] == '/';
+             /* check for DOS drive specifier */
+             if (!doaccess)
+                             if ( ( (name[0]>64 && name[0]<91) || (name[0]>96 && name[0]<123) ) && name[1]==':' && name[2] == '\\')
+                                doaccess = true;
               if (!doaccess) {
                               size_t namelen = strlen(name);
                               if (sizeof lsp->fullname - sizeof tzdirslash <= namelen)
diff --git a/private.h b/private.h
index ffb8121..58b3eab 100644
--- a/private.h
+++ b/private.h
@@ -470,6 +470,8 @@ struct tm *localtime_r(time_t const *restrict, struct tm *restrict);
time_t mktime(struct tm *);
time_t time(time_t *);
void tzset(void);
+struct tm *localtime(const time_t *timep);
 #if !HAVE_DECL_ASCTIME_R && !defined asctime_r

Manuela Friedrich

From: Paul Eggert [mailto:eggert at cs.ucla.edu]
Sent: Donnerstag, 1. Februar 2018 18:38
To: Manuela Friedrich <Manuela.Friedrich at actian.com>; Time Zone Mailing List <tz at iana.org>
Subject: Re: [tz] [PATCH] Support building zic.exe and zdump.exe natively on Windows with Visual Studio nmake.

On 02/01/2018 08:37 AM, Manuela Friedrich wrote:
> I managed to write a minimal tools.ini file for Windows that doesn't require changes of the Makefile so that compiling on POSIX systems will work as before.

Thanks, that sounds like a good way to go.

> It contains Windows versions of the version and version.h rules as these use shell commands in the base Makefile which will not work on Windows. Also, tools.ini contains any windows specific flags to the compiler, variables, suffixes and windows specific compilation rules.
> As explained earlier our customers will download the latest release from your ftp server and will need the tools.ini file and the getopt.c file as part of your latest release package.

Normally, downstream wrappers like this are maintained in downstream
packages, as the tzdb project itself doesn't have the maintenance oomph
to support all the downstream platforms ourselves. So I suggest that you
give your customers the tools.ini and getopt.c files as part of your
package; they can then use those files along with the downloaded data
and code from tzdb.

> Stat on Windows is documented on msdn:https://msdn.microsoft.com/en-us/library/14h5k7ff(v=vs.100).aspx<https://msdn.microsoft.com/en-us/library/14h5k7ff(v=vs.100).aspx>
> Having /. appended to a filename is not mentioned, potentially it's not expected.
> In the debugger I see stat returning 0 for an existing file with /. appended but -1 for a non-existing file with /. appended.

It's odd that "FOO/." acts like "FOO" when FOO is not a directory. Do
the following names also act like "FOO"? That is, on MS-Windows can one
append any number of ".", "/" and "\" to an ordinary filename without
affecting its interpretation, so long as every "." is preceded by a "/"
or "\"?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180207/def1a108/attachment-0001.html>

More information about the tz mailing list