Fix time API in gpgme
Open, NormalPublic

Description

gpgme mostly uses signed long int and time_t internally. This is of course a problem on 32 bit platforms and not only on Jan 19, 2038. gpg and in particular gpgsm takes great care to avoid this problem and gpgme parses this correctly. However, errors are sometime indicated by -1 and the question is whether this is needed at all.

We could simply change to unsigned long int and map errors to 0 or add an extra error flag. In most cases this will simply work but it would be an ABI break of course. Or we provide that new time API (tm) which we have in the work s for 15 years.

dkg added a subscriber: dkg.Oct 18 2018, 6:21 PM

what does "not only on Jan 19, 2038" mean here?

That it will not be a problem on that or near that date but already now because some use expiration times of 20 years.