[libcxx-commits] [libcxx] [libc++][chrono] Loads leap-seconds.list in tzdb. (PR #82113)

[Mark de Wever via libcxx-commits]

https://github.com/mordante commented:

> I think we should split out the interface for parsing TZDB-type strings.
> 
> I've noticed a number of complications arising from testing TZDB internals using only the public standard interface. The public interface is simply insufficient to allow proper testing and validation of the libraries internals.
> 
> I think we should split our concerns into two, They are:
> 
>     1. Implement & Test the C++ Standard interface.
> 
>     2. Implement a secure, platform/system agnostic TZDB parser/adapter.
> 
> 
> The latter of the two problems is much hairier of a task. There are a number of formats, each with a number of revisions, that we need the parser to accept. And more importantly, there's an infinite number of inputs we need the parser to securely reject.

The binary format files have different revisions. From what I can tell we only need to parse one revision for the text format.

> I say "securely" reject because the time zone database parser provides a potential attack vector for any attacker with some control over the bytes we read from disk. So validation using both unit tests and fuzzing tests is essential.
> 
> We can achieve this testibility without affecting the public interface by abstracting out the parser into a separate testable unit.

That would give a public symbol to the parser. I kept it all internal so we can adapt the code if the IANA database changes its format. Currently I need to parse two files, but who knows what happens in a few years time.
Since we can already feed hand-crafted databases to these tests I think we don't need to change anything for the testability.
 
> The remaining tests, for conformance of the public API, would look almost identical to what we have now, except with fewer places needing to reference internal implementation details.

I'm not sure what you exactly mean. There are public tests that don't use internals. There libc++ specific tests that use the internals. These private tests test boundary conditions. I think it would be too much effort to manually validate every permutation; we should use fuzz tests instead. 




https://github.com/llvm/llvm-project/pull/82113