PATH_MAX isn't guaranteed to be defined in Posix environments; it is
only on systems that have a path length limit, and even in environments
where it is defined its usage can lead to issues.
To avoid using PATH_MAX, I've made two main changes:
- Where realpath() was used, I've changed the code to use its
[POSIX.1-2008]'s new behaviour, where passing a null pointer as the
resolved_name buffer results in realpath() to automatically allocate
a buffer large enough to handle the given path, that is returned to
the caller. This has been supported for a long time as a GNU libc
extension before being standardized.
- Where readlink() was used, the size of the buffer was already
determined when calling lstat(); the returned struct stat contains a
st_size field, containing the number of bytes needed to store the
symbolic link contents. This meant that to avoid using the tricky
define I only needed to use a dynamically allocated buffer instead of
a static one, of size stat.st_size (+1 when a null terminator is
needed).
To make sure that memory is always freed, I've wrapped the new dynamic
allocations in an std::unique_ptr. The pointer returned by realpath()
must be freed with free(), so a unique_ptr with a custom deleter that
calls free() on destruction was used.
To read more about why PATH_MAX leads to buggy code I'd suggest reading
something like this: <https://eklitzke.org/path-max-is-tricky>.
[POSIX.1-2008]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html
When using `date` as a PRIVATE dependency, it is not required to install it. This flag give user using `date` with add_subdirectory the opportunity to disable install target Default behavior is conserved since ENABLE_DATE_INSTALL is ON
This gives user control over which folder header should be installed to instead of using hardcoded value `include/`.
Variable `CMAKE_INSTALL_INCLUDEDIR` is provided after a call to `include(GNUInstallDirs)`
More info can be found about usage in docs: https://cmake.org/cmake/help/latest/command/install.html
…of the interface
If the library gets compiled with HAS_STRING_VIEW=1, consumers always
need to link to the functions using std::string_view, as they are the
only ones compiled into the shared library.
You can find a longer explanation here:
<https://github.com/HowardHinnant/date/pull/754#issuecomment-1361248007>
date's internal init_tzdb function iterates through the files provided
by the tz database, and init_tzdb contains a list of files that should
not be interpreted as being in TZif format.
The 2023d release of the tz database added a new file that is not in
TZif format, zonenow.tab. However, this file had not been added to the
ignore list.
This caused date to intepret the zonenow.tab file as a TZif file,
which caused assertions to fire in debug mode if the user attempted to
load its associated time_zone, causing load_header() to be invoked
on the file, which would find that it did not contain a 'TZif' magic
number.
This commit addresses the issue by adding the file to the ignore list.
The announcement on the tz database mailing list which describes the
addition of zonenow.tab can be found at this link:
https://mm.icann.org/pipermail/tz-announce/2023-December/000080.html
