All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: "Pádraig Brady" <P@draigbrady.com>,
	"Paul Eggert" <eggert@cs.ucla.edu>,
	bug-gnulib@gnu.org, "Zack Weinberg" <zack@owlfolio.org>
Cc: Sam James <sam@gentoo.org>, distributions@lists.linux.dev
Subject: Re: recommending AC_SYS_YEAR2038_REQUIRED ?
Date: Mon, 10 Apr 2023 21:45:05 +0200	[thread overview]
Message-ID: <6250336.ySyUEvhnHf@nimes> (raw)
In-Reply-To: <bffe78fa-dc4d-46e5-8c2d-27f7aaa7baac@app.fastmail.com>

Zack Weinberg wrote:
> As the person who invented AC_SYS_YEAR2038_REQUIRED and
> AC_SYS_LARGEFILE_REQUIRED, let me say that it was my intention that they
> would only be used in rare circumstances, where the inability to install
> the software on older ABIs is outweighed by some other strong
> requirement for time_t and/or off_t to be at least 64 bits.  I didn't
> have any specific use cases in mind but I was imagining something to do
> with library ABIs involving time_t, or network and/or storage formats
> explicitly specified to use 64-bit counts of seconds since the Unix
> epoch, or similar.

Thanks for the clarification.

Note that I'm perfectly fine with AC_SYS_LARGEFILE_REQUIRED being
documented, because
  - it makes perfect sense for packages that regularly deal with files
    larger than 2 GiB, such as video manipulation,
  - hardly any platform nowadays lacks a way to enforce large files in
    the API.

Bruno




  reply	other threads:[~2023-04-10 20:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-10 13:40 recommending AC_SYS_YEAR2038_REQUIRED ? Bruno Haible
2023-04-10 14:12 ` Pádraig Brady
2023-04-10 19:09   ` Zack Weinberg
2023-04-10 19:45     ` Bruno Haible [this message]
2023-04-10 19:52     ` Paul Eggert
2023-04-10 21:08       ` Bruno Haible
2023-04-10 22:01         ` Paul Eggert
2023-04-10 21:42       ` Bruno Haible
2023-04-10 22:00         ` Paul Eggert
2023-04-10 22:36           ` Bruno Haible
2023-04-10 23:00             ` Paul Eggert
2023-04-12  0:10               ` Zack Weinberg
2023-04-19 21:23                 ` Paul Eggert
2023-04-19 22:53                   ` Zack Weinberg
2023-04-12  4:49             ` Sam James

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=6250336.ySyUEvhnHf@nimes \
    --to=bruno@clisp.org \
    --cc=P@draigbrady.com \
    --cc=bug-gnulib@gnu.org \
    --cc=distributions@lists.linux.dev \
    --cc=eggert@cs.ucla.edu \
    --cc=sam@gentoo.org \
    --cc=zack@owlfolio.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.