unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Lukasz Majewski <lukma@denx.de>, libc-alpha@sourceware.org
Cc: Joseph Myers <joseph@codesourcery.com>
Subject: Re: [PATCH v2 1/2] Y2038: make __mktime_internal compatible with __time64_t
Date: Mon, 11 Mar 2019 17:11:23 -0700	[thread overview]
Message-ID: <a238c752-2cfa-17f3-9676-943d75294aa3@cs.ucla.edu> (raw)
In-Reply-To: <20190227112042.1794-1-lukma@denx.de>

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.


> +/* Check whether a time64_t value fits in a time_t.  */
> +static inline bool
> +fits_in_time_t (__time64_t t64)
> +{
> +  time_t t = t64;
> +  return t == t64;
> +}
> +

This function is used only in time/mktime.c, and so should be defined
there. This will help sharing with Gnulib, which doesn't have
include/time.h.

The function's name should not end with "_t" since that's in the
reserved namespace (important for Gnulib).


> -verify (TYPE_IS_INTEGER (time_t));
> +verify (TYPE_IS_INTEGER (__time64_t));

Please remove this line instead. It dates back to old POSIX, which
allowed time_t to be a floating-point type. POSIX no longer allows this
and we needn't worry about that possibility any more.


> +  __time64_t t64;
> +  time_t t;
> +  struct tm tp0 = *tp;
There is no need for both t and t64. Just declare "__time64_t t;" and
replace all uses of t64 with t. Also, please consistently rename tp0 to
tm0, since it's not a pointer.


> +  t = t64;
> +  if (t != t64)

Replace this with "if (! fits_in_time_t (t))" (but rename the function).


> +/* The 32-bit-time wrapper.  */
> +time_t
> +mktime (struct tm *tp)
> +{
> +  __time64_t t64 = __mktime64 (tp);
> +  if (fits_in_time_t (t64))
> +    return t64;
> +  __set_errno (EOVERFLOW);
> +  return -1;
> +}

Fix this so that it doesn not modify *TP when failing due to EOVERFLOW.
The manual says mktime doesn't change *TP on failure.


Similar comments apply to the implementation of timegm.


  parent reply	other threads:[~2019-03-12  0:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27 11:20 [PATCH v2 1/2] Y2038: make __mktime_internal compatible with __time64_t Lukasz Majewski
2019-02-27 11:20 ` [PATCH v2 2/2] Fix time/mktime.c and time/gmtime.c for gnulib compatibility Lukasz Majewski
2019-03-12  0:12   ` Paul Eggert
2019-03-06 11:31 ` [PATCH v2 1/2] Y2038: make __mktime_internal compatible with __time64_t Lukasz Majewski
2019-03-12  0:11 ` Paul Eggert [this message]
2019-03-12  0:36   ` Joseph Myers
2019-03-17 22:48     ` Lukasz Majewski
2019-03-18 16:27       ` Joseph Myers
2019-03-19 10:53         ` Lukasz Majewski
2019-03-12  6:58   ` Lukasz Majewski
2019-03-18 21:23     ` Paul Eggert
2019-03-19 13:39       ` Lukasz Majewski
2019-03-19 23:12         ` Paul Eggert
2019-03-20  7:03           ` Lukasz Majewski
2019-03-22 21:49             ` Paul Eggert
2019-03-23 21:34               ` Lukasz Majewski
2019-03-24 22:17                 ` Lukasz Majewski
2019-03-23 11:59           ` Lukasz Majewski
2019-03-27 20:06             ` Paul Eggert
2019-03-28  8:59               ` Lukasz Majewski
2019-03-28 16:09                 ` Paul Eggert
2019-03-29 14:24                   ` Lukasz Majewski
2019-03-29 21:10                     ` Paul Eggert
2019-03-30 14:39                       ` Lukasz Majewski
2019-04-01 20:17                     ` Joseph Myers
2019-04-01 20:51                       ` Lukasz Majewski
2019-03-28 16:34                 ` Joseph Myers
     [not found]               ` <20190404120715.150a5d44@jawa>
     [not found]                 ` <20190424135748.502c34af@jawa>
2019-04-28 22:45                   ` Paul Eggert
2019-04-30  7:59                     ` Lukasz Majewski
2019-04-30 16:25                       ` Paul Eggert
2019-05-02  7:19                         ` Lukasz Majewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a238c752-2cfa-17f3-9676-943d75294aa3@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=lukma@denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).