[TUHS] 2.11BSD cross compiling update

[TUHS] 2.11BSD cross compiling update

[Nick Downing]

So I got a fair bit further advanced on my 2.11BSD cross compiler
project, at the moment it can make a respectable unix tree (/bin /usr
etc) with a unix kernel and most software in it. I unpacked the
resulting tarball and chrooted into it on a running SIMH system and it
worked OK, was a bit rough around the edges (missing a few necessary
files in /usr/share and that kind of thing) but did not crash. I
haven't tested the kernel recently but last time I tested it, it
booted, and the checksys output is OK.

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

So what I ended up doing was to port a tiny subset of 2.11BSD libc to
Linux, including its types. I copied the ctime.c module and prefixed
everything with "cross_" so there was "cross_time_t" and so forth, and
"#include <time.h>" became "#include <cross/time.h>", in turn this
depends on "#include <cross/sys/types.h>" and so on. That way, the
original logic worked unchanged.

I decided to also redo the cross compilation tools (as, cc, ld, nm,
ranlib and so on) using the same approach, since it was conceptually
elegant. This involved making e.g. "cross_off_t" and "struct
cross_exec" available by "#include <cross/a.out.h>", and obviously the
scheme extends to whatever libc functions we want to use. In
particular we use floating point, and I plan to make a "cross_atof()"
for the C compiler's PDP-11-formatted floating-point constant
handling, etc. (This side of things, like the cross tools, was
working, but was not terribly elegant before).

So then I got to thinking, actually this is an incredibly powerful
approach. Instead of just going at it piecemeal, would it not be
easier just to port the entire thing across? To give an example what I
mean, the linker contains code like this:
  if (nund==0)
    printf("Undefined:\n");
  nund++;
  printf("%.*s\n", NNAMESIZE, sp->n_name);
It is printing n_name from a fixed-size char array, so to save the
cost of doing a strncpy they have used that "%.*s" syntax which tells
printf not to go past the end of the char array. But this isn't
supported in Linux. I keep noticing little problems like this
(actually I switched off "-Wformat" which was possibly a bad idea). So
with my latest plan this will actually run the 2.11BSD printf()
instead of the Linux printf(), and the 2.11BSD stdio (fixing various
other breakage that occured because BUFSIZ isn't 512 on the Linux
system), and so on. What I will do is, provide a low level syscalls
module like cross_open(), cross_read(), cross_write() and so on, which
just redirect the request into the normal Linux system calls, while
adjusting for the fact that size_t is 16 bits and so forth. This will
be really great.

In case it sounds like this is over-engineering, well bear in mind
that one knotty problem I hadn't yet tackled is the standalone
utilities, for instance the 2.11BSD tape distribution contains a
standalone "restor" program which is essentially a subset of the
kernel, including its device drivers, packaged with the normal
"restor" utility into one executable that can be loaded off the tape.
It was quite important to me that I get this ported over to Linux, so
that I can produce filesystems, etc, at the Linux level, all ready to
boot when I attach them to SIMH. But it was going to be hugely
challenging, since compiling any program that includes more than the
most basic kernel headers would have caused loads of conflicts with
Linux's kernel headers and system calls. So the new approach
completely fixes all that.

I did some experiments the last few days with a program that I created
called "xify". What it does is to read a C file, and to every
identifier it finds, including macro names, C-level identifiers,
include file names, etc, it prepends the sequence "x_". The logic is a
bit convoluted since it has to leave keywords alone and it has to
translate types so that "unsigned int" becomes "x_unsigned_int" which
I can define with a typedef, and so on. Ancient C constructs like
"register i;" were rather problematic, but I have got a satisfactory
prototype system now.

I also decided to focus on 4.3BSD rather than 2.11BSD, since by this
stage I know the internals and the build system extremely intimately,
and I'm aware of quite a lot of inconsistencies which will be a lot of
work to tidy up, basically things that had been hurriedly ported from
4.3BSD while trying not to change the corresponding 2.8~2.10BSD code
too much. Also in the build system there are quite a few different
ways of implementing "make depend" for example, and this annoys me, I
did have some ambitious projects to tidy it all up but it's too
difficult. So a fresh start is good, and I am satisfied with the
2.11BSD project up to this moment.

So what will happen next is basically once I have "-lx_c" (the "cross"
version of the 4.3BSD C library) including the "xified" versions of
the kernel headers, then I will try to get the 4.3BSD kernel running
on top of Linux, it will be a bit like User-Mode Linux. It will use
simulated network devices like libpcap, or basically just whatever
SIMH uses, since I can easily drop in the relevant SIMH code and then
connect it up using the 4.3BSD kernel's devtab. The standalone
utilities like "restor" should then "just work". The cross toolchain
should also "just work" apart from the floating point issue, since it
was previously targeting the VAX which is little-endian, and the
wordsize issues and the library issues are taken care of by "xifying".
Very nice.

The "xifying" stuff is in a new repository 43bsd.git at my bitbucket
(user nick_d2).

cheers, Nick

[TUHS] 2.11BSD cross compiling update

[Steve Simon]

working with aged compilers is different. the biggest problem i had was the shared namespace for all structure members.

i had great success with hash8 many years ago. i am fairly sure that this still available in comp.sources.unix or comp.sources.misc.

-Steve


> On 13 Jan 2017, at 17:57, Nick Downing <downing.nick at gmail.com> wrote:
> 
> So I got a fair bit further advanced on my 2.11BSD cross compiler
> project, at the moment it can make a respectable unix tree (/bin /usr
> etc) with a unix kernel and most software in it. I unpacked the
> resulting tarball and chrooted into it on a running SIMH system and it
> worked OK, was a bit rough around the edges (missing a few necessary
> files in /usr/share and that kind of thing) but did not crash. I
> haven't tested the kernel recently but last time I tested it, it
> booted, and the checksys output is OK.
> 
> 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).
> 
> So what I ended up doing was to port a tiny subset of 2.11BSD libc to
> Linux, including its types. I copied the ctime.c module and prefixed
> everything with "cross_" so there was "cross_time_t" and so forth, and
> "#include <time.h>" became "#include <cross/time.h>", in turn this
> depends on "#include <cross/sys/types.h>" and so on. That way, the
> original logic worked unchanged.
> 
> I decided to also redo the cross compilation tools (as, cc, ld, nm,
> ranlib and so on) using the same approach, since it was conceptually
> elegant. This involved making e.g. "cross_off_t" and "struct
> cross_exec" available by "#include <cross/a.out.h>", and obviously the
> scheme extends to whatever libc functions we want to use. In
> particular we use floating point, and I plan to make a "cross_atof()"
> for the C compiler's PDP-11-formatted floating-point constant
> handling, etc. (This side of things, like the cross tools, was
> working, but was not terribly elegant before).
> 
> So then I got to thinking, actually this is an incredibly powerful
> approach. Instead of just going at it piecemeal, would it not be
> easier just to port the entire thing across? To give an example what I
> mean, the linker contains code like this:
>  if (nund==0)
>    printf("Undefined:\n");
>  nund++;
>  printf("%.*s\n", NNAMESIZE, sp->n_name);
> It is printing n_name from a fixed-size char array, so to save the
> cost of doing a strncpy they have used that "%.*s" syntax which tells
> printf not to go past the end of the char array. But this isn't
> supported in Linux. I keep noticing little problems like this
> (actually I switched off "-Wformat" which was possibly a bad idea). So
> with my latest plan this will actually run the 2.11BSD printf()
> instead of the Linux printf(), and the 2.11BSD stdio (fixing various
> other breakage that occured because BUFSIZ isn't 512 on the Linux
> system), and so on. What I will do is, provide a low level syscalls
> module like cross_open(), cross_read(), cross_write() and so on, which
> just redirect the request into the normal Linux system calls, while
> adjusting for the fact that size_t is 16 bits and so forth. This will
> be really great.
> 
> In case it sounds like this is over-engineering, well bear in mind
> that one knotty problem I hadn't yet tackled is the standalone
> utilities, for instance the 2.11BSD tape distribution contains a
> standalone "restor" program which is essentially a subset of the
> kernel, including its device drivers, packaged with the normal
> "restor" utility into one executable that can be loaded off the tape.
> It was quite important to me that I get this ported over to Linux, so
> that I can produce filesystems, etc, at the Linux level, all ready to
> boot when I attach them to SIMH. But it was going to be hugely
> challenging, since compiling any program that includes more than the
> most basic kernel headers would have caused loads of conflicts with
> Linux's kernel headers and system calls. So the new approach
> completely fixes all that.
> 
> I did some experiments the last few days with a program that I created
> called "xify". What it does is to read a C file, and to every
> identifier it finds, including macro names, C-level identifiers,
> include file names, etc, it prepends the sequence "x_". The logic is a
> bit convoluted since it has to leave keywords alone and it has to
> translate types so that "unsigned int" becomes "x_unsigned_int" which
> I can define with a typedef, and so on. Ancient C constructs like
> "register i;" were rather problematic, but I have got a satisfactory
> prototype system now.
> 
> I also decided to focus on 4.3BSD rather than 2.11BSD, since by this
> stage I know the internals and the build system extremely intimately,
> and I'm aware of quite a lot of inconsistencies which will be a lot of
> work to tidy up, basically things that had been hurriedly ported from
> 4.3BSD while trying not to change the corresponding 2.8~2.10BSD code
> too much. Also in the build system there are quite a few different
> ways of implementing "make depend" for example, and this annoys me, I
> did have some ambitious projects to tidy it all up but it's too
> difficult. So a fresh start is good, and I am satisfied with the
> 2.11BSD project up to this moment.
> 
> So what will happen next is basically once I have "-lx_c" (the "cross"
> version of the 4.3BSD C library) including the "xified" versions of
> the kernel headers, then I will try to get the 4.3BSD kernel running
> on top of Linux, it will be a bit like User-Mode Linux. It will use
> simulated network devices like libpcap, or basically just whatever
> SIMH uses, since I can easily drop in the relevant SIMH code and then
> connect it up using the 4.3BSD kernel's devtab. The standalone
> utilities like "restor" should then "just work". The cross toolchain
> should also "just work" apart from the floating point issue, since it
> was previously targeting the VAX which is little-endian, and the
> wordsize issues and the library issues are taken care of by "xifying".
> Very nice.
> 
> The "xifying" stuff is in a new repository 43bsd.git at my bitbucket
> (user nick_d2).
> 
> cheers, Nick

[TUHS] 2.11BSD cross compiling update

[Random832]

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)

[TUHS] 2.11BSD cross compiling update

[Nick Downing]

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 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170114/add3fb8e/attachment.html>

[TUHS] 2.11BSD cross compiling update

[Random832]

On Fri, Jan 13, 2017, at 23:41, Nick Downing wrote:
> 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.

POSIX doesn't even have the timezone files - it 'allows' for
implementation-defined timezones, but POSIX itself basically only
defines the System V TZ variable with a few extra bits to specify a
single set of daylight saving rules, e.g. "EST5EDT,M3.2.0,M11.1.0".

 Admittedly
> the
> 2.11BSD ctime/asctime/localtime/timezone stuff is simplistic and doesn't
> address complicated cases but it's good enough.

What's in 2.11BSD  (and 4.3BSD) is essentially the 1987 mod.sources
version of Arthur David Olson's timezone code, compare e.g.
https://github.com/eggert/tz/blob/c07b3825e1ae6e9d077a1d97088b853a79237a01/localtime.c
to
http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.11BSD/src/lib/libc/gen/ctime.c
- it's basically the same except for a few ifdefs and the presence of
asctime in the same file. The code has obviously evolved a lot since
then, but the binary zone file format is the same (except for some
backwards-compatible additions).

The code in 2.9BSD and 4.1BSD is much more simplistic, hardcoding US
daylight saving rules rather than looking up the applicable offset for a
timestamp from a table. What's interesting is that 4.2BSD's is arguably
"smarter" in some ways than either, calculating daylight savings based
on rules at runtime whereas today that is the province of zic. This used
the timezone structure of gettimeofday.

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

I guess I was considering my suggestion to be a "zic cross-compiler" -
which runs on the host system and is therefore not part of 2.11BSD
itself.

[TUHS] 2.11BSD cross compiling update

[Dan Cross]

On Fri, Jan 13, 2017 at 12:57 PM, Nick Downing <downing.nick at gmail.com>
wrote:

> [snip]
>
> So what I ended up doing was to port a tiny subset of 2.11BSD libc to
> Linux, including its types. I copied the ctime.c module and prefixed
> everything with "cross_" so there was "cross_time_t" and so forth, and
> "#include <time.h>" became "#include <cross/time.h>", in turn this
> depends on "#include <cross/sys/types.h>" and so on. That way, the
> original logic worked unchanged.
>
> I decided to also redo the cross compilation tools (as, cc, ld, nm,
> ranlib and so on) using the same approach, since it was conceptually
> elegant. This involved making e.g. "cross_off_t" and "struct
> cross_exec" available by "#include <cross/a.out.h>", and obviously the
> scheme extends to whatever libc functions we want to use. In
> particular we use floating point, and I plan to make a "cross_atof()"
> for the C compiler's PDP-11-formatted floating-point constant
> handling, etc. (This side of things, like the cross tools, was
> working, but was not terribly elegant before).
>
> So then I got to thinking, actually this is an incredibly powerful
> approach. [snip]
>

That sounds incredibly tedious. Can you specify a compiler flag to disable
searching the host /usr/include? Then you could set your own include path
and not have conflicts with headers from the host system. With, say, GCC
one could use `-ffreestanding` or `-nostdinc` and the like.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170114/ebd869d8/attachment.html>

[TUHS] 2.11BSD cross compiling update

[Nick Downing]

Yes, you are right, it is quite tedious. And yes, your idea is a good
one, and it echoes more or less the direction my thoughts have been
going in recent days. Originally I thought I'd only use the "cross_"
prefix where there were clear system-to-system differences (like in
the a.out stuff and the timezone stuff), then later I thought I'd use
the "x_" prefix everywhere, but I have realized as you say, this is
going to get annoying very quickly. It would be much better to be able
to work on the non-prefixed files, as it would feel much more natural.

So, in hindsight, given my decision that it's turned out to be too
much work and for too little benefit to port the cross toolchain to
glibc (as opposed to porting to gcc which is a given), it might have
been better to tackle it how you say. But on the other hand my "x_"
approach does have certain good points, which I will explain. Let's
consider the "stat" system call which some of the cross tools use.
Under my scheme I'll provide a prefixed version of "stat". Checking
"x_stat.h" in the 43bsd.git repo that I mentioned in my previous post,
I see this:

struct  x_stat
{
        x_dev_t x_st_dev;
        x_ino_t x_st_ino;
        x_unsigned_short x_st_mode;
        x_short x_st_nlink;
        x_uid_t x_st_uid;
        x_gid_t x_st_gid;
        x_dev_t x_st_rdev;
        x_off_t x_st_size;
        x_time_t        x_st_atime;
        x_int   x_st_spare1;
        x_time_t        x_st_mtime;
        x_int   x_st_spare2;
        x_time_t        x_st_ctime;
        x_int   x_st_spare3;
        x_long  x_st_blksize;
        x_long  x_st_blocks;
        x_long  x_st_spare4[2];
}

There are also some defines like "x_S_IFMT" which I will ignore for
brevity, but anyway the prefixed "stat" call will look something like:

#include <sys/x_stat.h>
#include <sys/stat.h>

x_int x_stat(char *x_pathname, struct x_stat *x_statbuf) {
        struct stat statbuf;
        if (stat(x_pathname, &statbuf) == -1) {
                x_errno = (x_int)errno;
                return -1;
        }
        x_statbuf->x_st_dev = (x_dev_t)statbuf.st_dev;
        x_statbuf->x_st_ino = (x_ino_t)statbuf.st_ino;
        ... fill in all other fields ...
        return 0;
}

Obviously, this gets a bit tedious too, and it also ignores issues
like converting the errno or what if ino_t is wider than x_ino_t...
but I think it will work sufficiently well for the cross toolchain.
With your suggestion I have no good way of creating a translation stub
like the above, because both "struct stat" will have the same name...
there are also lots more issues, like for instance some modules would
be compiled with "-nostdinc" and the like, plus other modules being
the translation stubs, would not... then all would be linked together,
the translation stubs would pull in the regular C library and there
would be conflicts everywhere. I think the "x_" prefix is the way to
go, but as you say it's a bit tedious, so I'll probably create
something like "x_cc" which automatically "xifies" the given C sources
to /tmp and then runs "gcc".

For the standalone utilities like "restor" it is less of an issue
since they are going to be compiled into a kernel subset and
everything will use the same "struct x_stat" so no translation will be
necessary. In the latter case, I'll provide emulated disk and tape
drivers which have an "x_" prefixed entry point to be called from the
kernel, but then revert to non-prefixed code which uses the native
Linux system calls like open(), read() and so on, and which I will
lift out of SIMH. So although the emulation backend is much simpler in
this case (it only has a few entry points, it doesn't need to provide
system-call-like services), it will still be much easier to write if I
have access to the "xification".

Another issue is the C types, since most code is written to use
"short", "int" and "long", a nice feature of the "xifier" is that it
changes this to "x_int" and therefore lets me change the width. It's
not a perfect emulation since pointers are still a different size and
the automatic promotions will be wrong (and varargs functions need
some massaging because of this). But it still substantially cuts down
the porting work that I have to do. I manually fixed up all this stuff
in the C compiler before, it was a big job and I still can't say
definitely it's robust.

cheers, Nick

So,

On Sat, Jan 14, 2017 at 6:17 PM, Dan Cross <crossd at gmail.com> wrote:
> On Fri, Jan 13, 2017 at 12:57 PM, Nick Downing <downing.nick at gmail.com>
> wrote:
>>
>> [snip]
>>
>> So what I ended up doing was to port a tiny subset of 2.11BSD libc to
>> Linux, including its types. I copied the ctime.c module and prefixed
>> everything with "cross_" so there was "cross_time_t" and so forth, and
>> "#include <time.h>" became "#include <cross/time.h>", in turn this
>> depends on "#include <cross/sys/types.h>" and so on. That way, the
>> original logic worked unchanged.
>>
>> I decided to also redo the cross compilation tools (as, cc, ld, nm,
>> ranlib and so on) using the same approach, since it was conceptually
>> elegant. This involved making e.g. "cross_off_t" and "struct
>> cross_exec" available by "#include <cross/a.out.h>", and obviously the
>> scheme extends to whatever libc functions we want to use. In
>> particular we use floating point, and I plan to make a "cross_atof()"
>> for the C compiler's PDP-11-formatted floating-point constant
>> handling, etc. (This side of things, like the cross tools, was
>> working, but was not terribly elegant before).
>>
>> So then I got to thinking, actually this is an incredibly powerful
>> approach. [snip]
>
>
> That sounds incredibly tedious. Can you specify a compiler flag to disable
> searching the host /usr/include? Then you could set your own include path
> and not have conflicts with headers from the host system. With, say, GCC one
> could use `-ffreestanding` or `-nostdinc` and the like.
>
>         - Dan C.
>

[TUHS] 2.11BSD cross compiling update

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

Random832 <random832 at fastmail.com> wrote:

> On Fri, Jan 13, 2017, at 23:41, Nick Downing wrote:
> > 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.
>
> POSIX doesn't even have the timezone files - it 'allows' for
> implementation-defined timezones, but POSIX itself basically only
> defines the System V TZ variable with a few extra bits to specify a
> single set of daylight saving rules, e.g. "EST5EDT,M3.2.0,M11.1.0".

We recently discussed whether we should add a pointer to the Olson code but we 
did not find a website that is expected to exist in 10+ yaers. It is however 
obvious that there is no known current implementation that uses a different 
implementation. So it would be obvious to mention that code in the POSIX 
standard.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/