refactor: move definition of time_t in uclibc#5144
Draft
dybucc wants to merge 1 commit into
Draft
Conversation
dybucc
force-pushed
the
uclibc-time_t-patch
branch
from
6bfd246 to
77686a8
Compare
Contributor
Author
|
CI is failing for reasons unrelated to the changes introduced in this PR. A rerun should do it. |
dybucc
force-pushed
the
uclibc-time_t-patch
branch
4 times, most recently
from
017fca3 to
bf22331
Compare
The uclibc-ng upstream project did not seem to provide different definitions for all of the target architectures for which the `libc` crate does provide different definitions. This patch aims to solve that by moving the prior type-specific definition of `time_t` to the top-level `unix/linux_like/linux/uclibc` module. `time_t` is now defined in terms of a platform- and implementation-specific `c_long`, which fits the default in upstream. There is a macro that the uclibc-ng project checks for to ensure that the type is 64-bits wide and not left to the system implementation, but that does not exist in the original uClibc. This patch does not add support for it.
dybucc
force-pushed
the
uclibc-time_t-patch
branch
from
bf22331 to
d68fe9f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR addresses bit-width representation issues under uClibc for the
time_ttype.Following the definition in upstream uclibc-ng (the maintained fork of uClibc,) this type should be defined in terms of either an
i64or ac_long. This depends on a macro,__UCLIBC_USE_TIME64__, that makes the latter one available in all systems, irrespective of machine word size or implementation memory model. This type is declared underlibc/sysdeps/linux/common/bits/types.h, in terms of other types inlibc/sysdeps/linux/common/bits/typesizes.h, with no alternative definitions for other platforms. The macro is not directly set by the library user, but rather issued at compile time as part of themakeconfiguration scripts that the library provides.Yet in the
libccrate,time_tunder thelinux/uclibcmodule has different definitions for all four of MIPS32, MIPS64, arm and x86_64. This patch changes that such that the definition is shared by all targets using uClibc, at the top-leveluclibc/mod.rsmodule instead. This does not, at present, affect L4Re.Tests are still pending on most platforms.
Sources
Upstream uclibc-ng sources showing the
types.hheader with the definition of the type thattime_tis defined as and the fragment from which that "nested" defintion stems from. Note the comment above the latter source below, where some developer left a note on the explicit GCC "bit-width configurations" uclibc-ng supports.Upstream uclibc-ng sources showing the use of the
__UCLIBC_USE_TIME64__macro to ensure the type of the type with whichtime_tis ultimately defined is either 64 bits or a Clong.Checklist
libc-test/semverhave been updated*LASTor*MAXare included (see #3131)cd libc-test && cargo test --target mytarget); especially relevant for platforms that may not be checked in CI