Issues with the embedded y2038 library

[p5pRT]

Migrated from rt.perl.org#128167 (status was 'open')

Searchable as RT128167$

[p5pRT]

From [email protected]

The Perl interpreter embeds a copy of Schwern's y2038 library, see file time64.c here​:

  http​://perl5.git.perl.org/perl.git/blob/HEAD​:/time64.c

I reported a few issues with this library, see this pull request of mine​:

  "Amendments to y2038"
  evalEmpire/y2038#9

However, Schwern is not responding anymore.

From that pull request, 2 particular issues stand out​:

Issue 1) Array indexing with the result of a boolean C comparison.

This is dangerous because (as far as I know) the C standard does not guarantee that the inteeger result of a comparison always 0 or 1 is.

In this particular case, simplified​:

  #define IS_LEAP(n) (blah_blah != 0)

  days += length_of_year[IS_LEAP(year)];

Issue 2) One of the date unit test cases fails.

This makes me worry that the date/time calculations may fail at some point in time in the future.

[p5pRT]

From [email protected]

R. Diez wrote​:

Issue 1) Array indexing with the result of a boolean C comparison.

This is dangerous because (as far as I know) the C standard does not
guarantee that the inteeger result of a comparison always 0 or 1 is.

The C standard guarantees precisely that, and always has. Operators
yielding a truth value always yield integer 0 or 1.

-zefram

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From [email protected]

The C standard guarantees precisely that, and always has. Operators
yielding a truth value always yield integer 0 or 1.

You are right, my mistake.

I would still change it, though. It is not obvious that the result of IS_LEAP() is going to be used to index an array, so the slightest change to IS_LEAP() could break the code. Therefore, I would make it explicit somehow, perhaps by changing the macro name, or just by adding a comment next to it.