[tz] tabs vs spaces
Guy Harris
guy at alum.mit.edu
Fri May 3 17:34:17 UTC 2013
On May 3, 2013, at 6:32 AM, Robert Elz <kre at munnari.oz.au> wrote:
> Rather we should be encouraging people to use the binary output files from
> zic for almost all purposes when they need something more than standard
> libc functions provide. And if that means documenting that format, more
> than is already done, then let's do it.
Do we need more than tzfile(5), which we already have? ("More" over and above "making HTMLified man pages available from http://www.iana.org/time-zones or a page under it", which is something I think wout be a good thing to do.)
> It is already difficult to the point
> of almost impossibility to make much in the way of changes to that file format,
> as it is understood by system's libc functions, that we cannot alter - and
> even where libc is normally shared (and so can be updated if needed) nothing
> compels users to use the shared version - static program linking works on
> every system I'm aware of.
$ cat static.c
#include <stdio.h>
#include <time.h>
int
main(void)
{
time_t now = time(NULL);
printf("%s", ctime(&now));
return 0;
}
$ gcc -static -o static static.c
ld: library not found for -lcrt0.o
collect2: ld returned 1 exit status
and it's
$ uname -sr
Darwin 12.2.1
better known as
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.8.2
BuildVersion: 12C3012
And also:
$ gcc -static -o static static.c
ld: fatal: library -lc: not found
ld: fatal: file processing errors. No output written to static
collect2: ld returned 1 exit status
and it's
$ uname -sr
SunOS 5.11
better known as "the OS component of Solaris 11".
And, no, as far as I know clang won't help on OS X and Sun C^W^WOracle Studio won't help on Solaris. Both OSes have an explicit policy of *disallowing* static linking, so that they can change implementations of system APIs under the hood *without* having to worry about out-of-date implementations being built into statically-linked binaries.
(And, yes, even process 1 runs dynamically-linked code.)
However, there are *other* UN*Xes where static linking *is* allowed, so we still have to worry about that.
As random832 at fastmail.us suggested, we can add new information to the end. There's also a version field in the header, and the only check currently done by our localtime.c is to see whether it's '\0' or not; the "new format", with 64-bit time support, has '2' in that field, and, unless some other reader is out there, we could set it to '3' for a new version with additional information at the end (and maybe some information in the reserved field if necessary).
More information about the tz
mailing list