I see, no I had not realized that code is still in use, I would have thought it had been replaced by a whole lot of POSIX bloat. Admittedly the 2.11BSD ctime/asctime/localtime/timezone stuff is simplistic and doesn't address complicated cases but it's good enough.

However I have to resist the temptation to improve or update stuff in 2.11BSD, I went down that path many times (with the Makefiles project for instance) and because everything is interdependent you always introduce more problems and get deeper and deeper enmeshed. In order to stay in control I only fix essentials and apply a rule of minimal change, period. This applies until I have a baseline that builds exactly the same binary system image as the native build. Then I might proactively improve parts of the system but I will not do it reactively if you follow.

As I see it the zic behaviour is not a bug since time_t is 32 bits on 2.11BSD and has no unreasonable values, and localtime() is BSD not POSIX compliant and is not allowed to return NULL.

cheers, Nick

On 14/01/2017 6:53 AM, "Random832" <random832@fastmail.com> wrote:
On Fri, Jan 13, 2017, at 12:57, Nick Downing wrote:
> I then ended up doing a fair bit of re-engineering, how this came
> about was that I had to port the timezone compiler (zic) to run on the
> Linux cross compilation host, since the goal is eventually to build a
> SIMH-bootable disk (filesystem) with everything on it. This was a bit
> involved, it crashed initially and it turned out it was doing
> localtime() on really small and large values to try to figure out the
> range of years the system could handle. On the Linux system this
> returns NULL for unreasonable time_t values which POSIX allows it to
> do. Hence the crash. It wasn't too obvious how to port this code. (But
> whatever I did, it had to produce the exact same timezone files as a
> native build).

You know that the timezone file format that it uses is still in use
today, right? There's extra data at the end in modern ones for 64-bit
data, but the format itself is cross-platform, with defined field widths
and big-endian byte order.

What do you get when you compare the native built timezone files with
one from your linux host's own zic? It *should* only differ by the
version number in the header [first five bytes "TZif2" vs "TZif"] and
the 64-bit section, if you're giving it the same input files. And I bet
you could take the current version of the code from IANA and, if it
matters to you, remove the parts that output the 64-bit data. If nothing
else, looking at the modern code and the version in 2.11BSD side-by-side
will let you backport bug fixes.

(Note: Technically, the version present in most Linux systems is a fork
maintained with glibc rather than the main version of the code from
IANA)