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

	        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