14 Jan
2017
14 Jan
'17
10:41 a.m.
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(a)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)