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

Reply via email to