[Toybox] Stat %Z - What are valid values?

Rob Landley rob at landley.net
Fri Dec 30 13:44:09 PST 2016

I have negotiated a 3 day weekend for the holidays! Starting today. Ok,
catching up...

On 12/30/2016 01:39 PM, enh wrote:
> time_t on 32-bit Android is 32 bits.
> that particular value looks like a sign-extension of 0xAFBEADCE, which
> is still some time in 2063.

Or if it's signed, that's -1346458162 which would be... sometime in the
1930's? hmmm... "./date -D %s -d -1346458162" is failing under glibc,
and failing _differently_ under musl. (Wheee.)

/me goes down tangent rathole debugging why. (THIS is why I need to
finish mkroot and get a toybox test environment set up that can test
stuff requiring root access under qemu under a known root filesystem and
kernel config. Is my code broken, or does strptime not parse negative
numerical arguments for %s format?)

(Answer: musl doesn't implement %s at all, and glibc doesn't allow the
%s value it converts to be negative. And of course posix doesn't specify
signed OR unsigned for time_t at
because actually providing enough detail to implement things would be

> two patches attached. one avoids sign extension for all calls to
> `out`, fixing %Z for systems with a signed 32-bit time_t.

The 0001-Avoid* patch only has the first hunk, which defines two macros
there are never used and renames a function but not its users.

>> This seems suspiciously large and I'm wondering what the valid range for
>> this value is.

I think we all do at this point.


More information about the Toybox mailing list