public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Lukasz Majewski <lukma@denx.de>
Cc: Paul Eggert <eggert@cs.ucla.edu>,
	Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	Florian Weimer <fweimer@redhat.com>,
	GNU C Library <libc-alpha@sourceware.org>,
	Siddhesh Poyarekar <siddhesh@redhat.com>,
	Andreas Schwab <schwab@suse.de>,
	Stepan Golosunov <stepan@golosunov.pp.ru>,
	Alistair Francis <alistair.francis@wdc.com>
Subject: Re: [RFC 1/6] y2038: Introduce _TIME_BITS flag to support 64 bit time on 32 bit systems
Date: Sat, 5 Dec 2020 00:12:44 +0000	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2012050004380.240600@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20201204233604.7430-2-lukma@denx.de>

On Sat, 5 Dec 2020, Lukasz Majewski wrote:

> This change introduces new compile time, supported by glibc flag - namely
> _TIME_BITS, which then is responsible for exporting __USE_TIME_BITS64 only

As a major new user-visible feature, this needs to be mentioned in NEWS.

> +/* We need to know the word size in order to check the time size.  */
> +#include <bits/wordsize.h>
> +
> +#if defined _TIME_BITS
> +# if _TIME_BITS == 64
> +#  if ! defined (_FILE_OFFSET_BITS) || _FILE_OFFSET_BITS != 64
> +#   error _TIME_BITS==64 is allowed only when _FILE_OFFSET_BITS==64
> +#  elif __WORDSIZE == 32
> +#   define __USE_TIME_BITS64	1
> +#  endif

__WORDSIZE isn't the right thing to check.  On ARC or RV32 or x32, 
_TIME_BITS == 64 should be a no-op, because time_t has always been 64-bit 
for those glibc ports.  That is, you should be checking __TIMESIZE, not 
__WORDSIZE.

> +# elif _TIME_BITS == 32
> +#  if __WORDSIZE > 32
> +#   error _TIME_BITS=32 is not compatible with __WORDSIZE > 32

Likewise, __TIMESIZE should be checked here, not __WORDSIZE.

> +@defvr Macro _TIME_BITS
> +This macro determines the bit size of @code{time_t} (and therefore the
> +bit size of all @code{time_t} derived types and the prototypes of all
> +related functions). If @code{_TIME_BITS} is undefined, the bit size of
> +time_t equals the bit size of the architecture.

Apart from "bit size of the architecture" not being well-defined, that's 
not right for ARC or RV32, 32-bit architectures with 64-bit time_t.

Note there should be two spaces after "." in Texinfo manuals.

> +If @code{_TIME_BITS} is undefined, or if @code{_TIME_BITS} is defined
> +to the value @code{32} and @code{__WORDSIZE} is defined to the value
> +@code{32}, or or if @code{_TIME_BITS} is defined to the value @code{64}
> +and @code{__WORDSIZE} is defined to the value @code{64}, nothing changes.

__WORDSIZE (and __TIMESIZE after the fix above) is not a user-visible 
interface, it's a glibc header implementation detail.  The manual (other 
than maint.texi) should not mention either such internal macro; you need 
to talk about a concept of word size / default time_t size that's 
explained purely in user-level interfaces, not glibc internal macros.

> +If @code{_TIME_BITS} is defined to the value @code{64} and if
> +@code{__WORDSIZE} is defined to the value @code{32}, then the @w{64 bit}
> +time API and implementation are used even though the architecture word
> +size is @code{32}. Also, if the kernel provides @w{64 bit} time support,
> +it is used; otherwise, the @w{32 bit} kernel time support is used (with
> +no provision to address kernel Y2038 shortcomings).

Use "32-bit" and "64-bit" (with hyphen) as adjectives.

-- 
Joseph S. Myers
joseph@codesourcery.com

  reply	other threads:[~2020-12-05  0:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04 23:35 [RFC 0/6] y2038: Prepare glibc to be Y2038 safe for 32 bit ports Lukasz Majewski
2020-12-04 23:35 ` [RFC 1/6] y2038: Introduce _TIME_BITS flag to support 64 bit time on 32 bit systems Lukasz Majewski
2020-12-05  0:12   ` Joseph Myers [this message]
2020-12-07 13:00     ` Lukasz Majewski
2020-12-04 23:36 ` [RFC 2/6] y2038: stat: {f}stat{at}64_time64 redirection to be used on Y2038 systems Lukasz Majewski
2020-12-05  0:04   ` Joseph Myers
2020-12-07 10:28     ` Lukasz Majewski
2020-12-07 18:07       ` Joseph Myers
2020-12-04 23:36 ` [RFC 3/6] y2038: Export struct_stat_time64_helper.h with Y2038 safe stat{64} content Lukasz Majewski
2020-12-29 10:30   ` Lukasz Majewski
2020-12-04 23:36 ` [RFC 4/6] y2038: Enhance struct msqid_ds to support 64 bit time Lukasz Majewski
2020-12-29 10:34   ` Lukasz Majewski
2020-12-04 23:36 ` [RFC 5/6] msqid: Provide internal copy of struct __msqid64_ds Lukasz Majewski
2020-12-29 10:54   ` Lukasz Majewski
2020-12-04 23:36 ` [RFC 6/6] msg: provide glibc local copy of struct msqid_ds Lukasz Majewski
2020-12-05  0:01 ` [RFC 0/6] y2038: Prepare glibc to be Y2038 safe for 32 bit ports Joseph Myers
2020-12-07 10:22   ` Lukasz Majewski
2020-12-07 18:01     ` Joseph Myers
2020-12-08 10:07       ` Lukasz Majewski
2020-12-08 15:25         ` Joseph Myers
2020-12-13 11:49           ` 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

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

  git send-email \
    --in-reply-to=alpine.DEB.2.22.394.2012050004380.240600@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=alistair.francis@wdc.com \
    --cc=eggert@cs.ucla.edu \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=lukma@denx.de \
    --cc=schwab@suse.de \
    --cc=siddhesh@redhat.com \
    --cc=stepan@golosunov.pp.ru \
    /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).