refactor: move definition of time_t in uclibc#5144
Draft
dybucc wants to merge 1 commit into
Draft
Conversation
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
6bfd246 to
77686a8
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 under
libc/sysdeps/linux/common/bits/types.h,in terms of other types in
libc/sysdeps/linux/common/bits/typesizes.h, with no alternativedefinitions for other platforms.
Yet in the
libccrate,time_tunder theuclibcmodule has different definitions for all fourof MIPS32, MIPS64, arm and x86_64. This patch changes that such that the definition is shared by all
targets using uClibc, at the top-level
uclibc/mod.rsmodule instead.Tests are still pending on all platforms, but this PR has been open anyway to show part of
yesterday's work.
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 thecomment 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 typeof the type with which
time_tis ultimately defined is either 64 bits or a Clong.Checklist
libc-test/semverhave been updated*LASTor*MAXareincluded (see #3131)
cd libc-test && cargo test --target mytarget);especially relevant for platforms that may not be checked in CI