Date: Fri, 27 Jul 2018 12:57:36 +0100 From: Ralph Corderoy <ra...@inputplus.co.uk> Message-ID: <20180727115736.c2ca421...@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