Date: Fri, 27 Jul 2018 12:57:36 +0100
From: Ralph Corderoy <ralph@inputplus.co.uk>
Message-ID: <20180727115736.C2CA421994@orac.inputplus.co.uk>
| No, it calls the hoary parsedate(3),
Yes, I know, so strings like "@nnn + 3 hours" are accepted...
| but despite the man page, it's not obvious to me that the `epochdate'
| rule indicates the gmtime_r(3) error.
The man page looks to be wrong...
| GNU date also accepts text that doesn't match the Reproducible-Builds
| spec.
Not a great surprise.
| Here's the specification again.
| https://reproducible-builds.org/specs/source-date-epoch/#idm53
| It doesn't sufficiently spell out what's valid.
|
| The value MUST be an ASCII representation of an integer with no
| fractional component, identical to the output format of date +%s.
I am not sure what is unclear about that. But that is really an admonition
to whoever supplies the value, rather than to anything which is checking it.
| So that means it matches /^(0|-?[1-9][0-9]*)$/ in the interval
| [-67768040609740800, 67768036191676800) given a 64-bit signed time_t
time_t is allowed to be unsigned (though it rarely is) and there is no limit
to 64 bits (though I find it hard to imagine a use for anything wider.)
| with a 32-bit signed year. (Though POSIX doesn't state time_t need be
| bigger than 32 bits, or if it's signed.)
No, it doesn't. The 32 bit signed year is kind of a problem though, that
one might run out...
| It SHOULD be set to the last modification time of the source,
| incorporating any packaging-specific modifications.
|
| That would bring it back into reasonable bounds, but it's only a SHOULD.
Yes - but personally I think it reasonable to assume, for nmh building
purposes, that the source date is >= 1970 (I would doubt very much that
any part of MN existed in 1970 or before, and I know that nmh did not.)
| I'm thinking if it matches the above regexp, and gmtime(3) is happy,
| then that's good enough.
I think if you just test that it is all digits, that would be enough, and if
you like, that gmtime (or at least, whatever date -d@ (or date -r) does
to process it) can parse the thing to get rid of absurlly big out of range
values.
But I would be just as happy to simply use the string given and not attempt
to verify it at all. I don't much care what the "reproducible builds spec"
demands. Making the build reproducible (given rational input) is a good idea,
being over backwards to meet someone's arbitrary idea on how to do
that is not.
kre
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers