Potential issues with the snippet to parse SOURCE_DATE_EPOCH in C

[Chris Lamb]

Hey folks,

We've been using the following snippet of code to parse the value of
SOURCE_DATE_EPOCH in the C programming language:

    https://reproducible-builds.org/docs/source-date-epoch/#c

I'm not 100% sure who originally wrote this code, but it was probably
sometime in the ~2015 era, and it must be in a huge number of codebases
by now.

Anyway, Alejandro Colomar was working on the shadow security tool and
pinged me regarding some potential issues with the code. You can see
this conversation here:

  https://github.com/shadow-maint/shadow/commit/cb610d54b47ea2fc3da5a1b7c5a71274ada91371#r136407772

... but for context here, it kicks off with:

> Was there any reason to reject >ULONG_MAX? I'm touching this code,
> and don't see a reason for it; it looks very arbitrary; especially
> since some systems can have 32-bit long, but 64-bit time_t. Should I
> just drop that check, or keep it? And why?

As you can see from the exchange (re. 32-bit/64-bit time_t etc.), I am
not 100% sure of myself in this area. But I did promise I'd bring it
up here on this list and solicit input, etc.

Note that Alejandro goes onto say:

> I have written a set of fixes for this function, in this PR: #893
> (still a draft)
> [See: https://github.com/shadow-maint/shadow/commit/cb610d54b47ea2fc3da5a1b7c5a71274ada91371#r136481852 ]

… and on that PR, Alejandro writes:

> I was wondering... maybe I could write a library, libgetnum, and add
> these functions there. That way, all those code bases in Debian that
> have the problem we found in gettime() could be fixed easily by just
> calling getnum() internally as I did here.
>
> I also fixed so many other hidden bugs in this PR, that other
> projects could benefit from such a library.

Speaking just for myself, I worry that most codebases won't rush to
introduce a new library dependency "just" to parse this value (even if
they should), but no doubt we should iron out any problems in the
snippet regardless.

Either way, I hope some folks who are better at this kind of C /
systems programming can jump in and iron out any potential issues with
Alejandro.


Best wishes,

-- 
      o
    ⬋   ⬊      Chris Lamb
   o     o     reproducible-builds.org 💠
    ⬊   ⬋
      o