Re: [nmh-workers] Reproducible build patch

[Ralph Corderoy]

Hi kre,

> The point is that the "try this" or "try this" ... stuff in order to
> find an arg sequence for date that works also allows invalid values
> for the input time to be ignored,

You still seem to be referring to the first version I wrote?
Here's the second one again that's being replied to.

> >     +fmt='%Y-%m-%d %T %z'
> >     +now=${SOURCE_DATE_EPOCH-$(date +%s)}
> >     +if date -u -d @42 +"$fmt" >/dev/null 2>&1; then   # Coreutils.
> >     +    date=$(date -u -d "@$now" +"$fmt")
> >     +elif date -u -r 42 +"$fmt" >/dev/null 2>&1; then   # BSD.
> >     +    date=$(date -u -r "$now" +"$fmt")
> >     +else   # Posix, ignoring SOURCE_DATE_EPOCH.
> >     +    date=$(date -u +"$fmt")
> >     +fi
>
> that is, on a system that does not support
>
>       date -d @NNN ....
>
> date will (should) fail, but on a system where -d @NNN is
> supported, date will fail if NNN is invalid, and given stderr is
> sent o /dev/null, will fail in a more or less indistinguishable way.

The first invocation of `date -d @NNN' uses `42', not the user's
$SOURCE_DATE_EPOCH and discards stderr.  If its exit value is good then
the second `date -d @NNN' uses $SOURCE_DATE_EPOCH and doesn't discard
stderr, nor the exit value.

> if [ "${SOURCE_DATE_EPOCH+set}" ]
> then
>       case "${SOURCE_DATE_EPOCH}" in
>       '' | *[!0-9]*)
>               printf '%s\n' >&2 \
>                    "Invalid SOURCE_DATE_EPOCH='${SOURCE_DATE_EPOCH}'"
>               exit 1
>               ;;
>       esac
> fii
>
> or something along those lines.  That way at least the source of the
> problem is known.

Well, it spots some flaws with SOURCE_DATE_EPOCH.

    $ n=67768036191676799
    $ date -ud @$n
    2147485547-12-31 23:59:59 +0000 Wed
    $ let n++
    $ date -ud @$n
    /bin/date: time ‘67768036191676800’ is out of range
    $

> If you do that, you don't need to rely as much upon versions of date
> doing proper error checking of their input (I have no idea how good
> NetBSD is at detecting a bad value after date address@hidden (which is
> supported, as is -r) for example, it might just convert digits and
> ignore later noise.

Yes, they might fling it at atoi(3), I agree.  I don't think that's
nmh's look out, and date is best off checking the parameter.

> ps: -e is one of the lest relaible features of sh (not in
> implementations, so much, but its definition, and then usage
> expectations) - it is best not to rely upon it, and rather add "||
> fail Message" after any command that you actually want to check the
> exit status off (where fail is a function that DTRT).

OK, but I want all of them checked apart from those I explicitly `||
true'.  That suggests a lot of clutter, or a lot of `&&' chaining before
the `|| true'.

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