This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 1/2] Y2038: make __mktime_internal compatible with __time64_t
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Lukasz Majewski <lukma at denx dot de>, <libc-alpha at sourceware dot org>
- Date: Tue, 12 Mar 2019 00:36:11 +0000
- Subject: Re: [PATCH v2 1/2] Y2038: make __mktime_internal compatible with __time64_t
- References: <20190227112042.1794-1-lukma@denx.de> <a238c752-2cfa-17f3-9676-943d75294aa3@cs.ucla.edu>
On Mon, 11 Mar 2019, Paul Eggert wrote:
> On 2/27/19 3:20 AM, Lukasz Majewski wrote:
> > +/* Another name for `__mktime64'. */
> > +extern __time64_t __timelocal64 (struct tm *__tp) __THROW;
>
> In hindsight the name 'timelocal' was a mistake: it's not a portable
> name and its use has not caught on. Although we need to keep 'timelocal'
> for backwards compatibility, there's no need to define 'timelocal64', as
> the very few people who need such a function can just call mktime64. So
> I suggest removing all traces of timelocal64, __timelocal64, etc. from
> the patch.
Neither timelocal64 nor mktime64 will be a public API; the public API is
to define _TIME_BITS=64 (and _FILE_OFFSET_BITS=64 because we don't want to
support the combination of 64-bit times with 32-bit offsets) before
including any system headers, then call the existing function names.
Given timelocal as part of the __USE_MISC API in time.h, it should be part
of the __USE_MISC __TIME_BITS=64 API there as well - but it's fine for
that case to redirect to __mktime64 (and thus not need __timelocal64 as
another alias).
--
Joseph S. Myers
joseph@codesourcery.com