[REVIEW] 16352 strftime_l() should be more careful with pointer arithmetic

[REVIEW] 16352 strftime_l() should be more careful with pointer arithmetic

[Bill Sommerfeld]

Issue: https://www.illumos.org/issues/16352
CR: https://code.illumos.org/c/illumos-gate/+/3432
Diff: 
https://code.illumos.org/~diff/74fcc6a236cd4f31a1f7be52d30472203759b158

This change fixes corruption of the output of the ascftime function
and fixes a minor flaw in our implementation of strftime and
strftime_l which is exposed by our implementation of ascftime.

The underlying implementation converts a (start, length) into a
(start, end), and plows onward if the computation of end overflows and
wraps around.  It uses a mix of  (ptr < end) and (ptr == end) tests,
with the result that some of the format string is passed through into
the output buffer.

The fix is to detect the overflow and clamp the end pointer to the
largest possible pointer value.
	
ascftime (an obsolete interface that nobody should use) is not passed
a buffer length; not having a length, it passes LONG_MAX as the buffer
length to strftime.  If the buffer passed to ascftime lies in the
upper half of the address space, the end computation overflows,
triggering the bug.

In a default build of illumos on amd64, the 64-bit user stack lives
above the address space gap, though at least one distribution sets
_userlimit to below the address space gap, masking the bug in
ascftime.

I've added a regression test that verifies the fix, including a
variant that detects the bug even if the buffer lies in the lower half
of the virtual address space.