False syscall dependencies

[Shaun Jackman]

For an embedded system with no kernel, and thus no system call
support, I wanted to check that the application didn't call any
syscalls, because havoc would surely result. I found system calls were
in fact included in the resulting binary. This realisation led to a
two day jaunt to discover why. I finall found that...

	(where `->' reads as `is sucked in by')
	_write_r -> __swrite -> __sinit -> __svfscanf_r -> sscanf ->
	_tzset_r -> tzset -> _setenv_r -> _putenv_r -> putenv

... and so the application's use of putenv caused stdio and the system
calls to be sucked in.

I'm wondering if it's possible to break two of these dependencies. One
is the dependency of setenv on tzset. The second is of sscanf on
_write.

Rather than setenv calling tzset, which is an unfortunate dependency,
the time formatting functions, namely ctime, localtime, mktime, and
strftime, could call tzset. This is the approach suggested by SUSv3.
Would a patch be well received?

Due to the rather elegant super-function, __svfscanf_r, depending on
__sinit and thus _write, I don't see a simple way of avoiding sscanf
sucking in the syscalls. One idea is to replace __sinit with
__sinit_without_syscalls and __sinit_with_syscalls (named
extra-verbosely for clarity), and remove the call to __sinit in
__svfscanf_r, and have sscanf call __sinit_without_syscalls, whereas
fscanf would call __sinit_with_syscalls.

Cheers,
Shaun