Hi kre,

> As I said, I know (somewhat) the -d parser on netbsd, which I know
> handles the @N form, but I kind of doubt has much in the way of error
> checking there.

No, it calls the hoary parsedate(3),
http://cvsweb.netbsd.org/bsdweb.cgi/src/bin/date/date.c?rev=1.61&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
http://netbsd.gw.com/cgi-bin/man-cgi?parsedate++NetBSD-current
but despite the man page, it's not obvious to me that the `epochdate'
rule indicates the gmtime_r(3) error.
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libutil/parsedate.y?rev=1.32&content-type=text/x-cvsweb-markup

GNU date also accepts text that doesn't match the Reproducible-Builds
spec.

    $ date -ud '@  003.1415'
    1970-01-01 00:00:03 +0000 Thu

> If you really believe in that, then you need to do the validation.

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.

So that means it matches /^(0|-?[1-9][0-9]*)$/ in the interval
[-67768040609740800, 67768036191676800) given a 64-bit signed time_t
with a 32-bit signed year.  (Though POSIX doesn't state time_t need be
bigger than 32 bits, or if it's signed.)

    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.

I'm thinking if it matches the above regexp, and gmtime(3) is happy,
then that's good enough.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

-- 
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Reply via email to