https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
Nicolas Boulenguez <nicolas at debian dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #59360|0 |1
is obsolete| |
Attachment #59644|0 |1
is obsolete| |
Attachment #59645|0 |1
is obsolete| |
--- Comment #37 from Nicolas Boulenguez <nicolas at debian dot org> ---
Created attachment 61037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61037&action=edit
v14 to_duration_64 musl
Hello.
Sorry for the answer delay.
I wonder what is blocking patch 3, which fixes one word in the documentation.
v14 is rebased on fdbe017b.
I will test it again after we are done with style issues and painful rebase
work.
> > I have no way to guess what kind of merge you will prefer in this
> > context.
> we can't change the Calendar API. User code using the new "*_64"
> function will break.
> A possible solution would be to implement the API using your change.
Improving these functions is not a prerequisite for my patches.
Here are some suggestions to anyone working on them.
Ada.Calendar.To_Duration_64 and To_Timespec_64 are in the private part,
and only used by the body of Ada.Calendar_Conversions.
Apparently, this scheme was necessary for Ada private types,
but not for Interfaces.C.*.
Most issues described in the header of my commit introducing C_Time
also affect these two functions. For example,
To_Timespec (0, Sec, Nsec)
should not set Sec to -1.
When Duration has 64 bits and time_t has 32 bits, should
To_Timespec (2.0**33, Secs, Nsecs)
set Secs and Nsecs to the correct converted values,
or report an error because the user will almost certainly call
a C function with the resulting Secs,
and the C function will return random data or crash?
The second option is trivial to implement on top of System.C_Time.
The first one probably requires some duplication of the implementations
and python tests.
> +#if defined(__USE_TIME64_REDIRECTS) || (__TIMESIZE == 32 &&
> __USE_TIME_BITS64)
> + C("Glibc_Use_Time_Bits64", Boolean, "True", "Y2038 Glibc transition")
> Would it make sense to drop the "Glibc" here? Having "Glibc" means
> that we end up with glibc specifics in files that are not glibc
> specific (e.g. a-exetim__posix.adb or s-osinte__linux.ads).
> Are these particular macros glibc specific? We need these to build
> with other libc (e.g. musl).
Could you be more specific about the changes you have in mind? These
macros seem specific to glibc, but I hardly see how they could break a
build with musl (unless musl uses the same macros for a different
purpose, which seems unlikely).
You probably want the glibc patch for this bug easily extensible, in
case someone tries to also fix musl.
Is a musl fix a prerequisite for applying the glibc fix?
Do you want the symbol names imported as static strings in
s-oscons-tmplt.c, then each file importing with
External_Name => System.OS_Constants.Foo_External_Name ?
Just as a discussion basis, the attached patch 2 replaces the boolean
with an enumerated type, and adds the Musl External_Names as far as I
understand them in https://musl.libc.org/time64.html.
Note however that _REDIR_TIME64 is not documented and will never be
https://www.openwall.com/lists/musl/2013/03/29/13
so testing a fix on musl won’t be straightforward.
A ./configure test may be necessary.
