Re: On time64 and Large File Support

--Apple-Mail=_991A15E1-C762-43A1-8C6C-BDB1DC1732D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 30 Dec 2022, at 22:12, Paul Eggert <[email protected]> wrote:
>=20
> On 12/28/22 20:02, Zack Weinberg wrote:
>=20
>> Please revert that part of your follow-up patch.
> OK, I reverted all that patch, except for the further changes you =
requested, plus some minor quoting and version-number fixes in comments.
>=20
>> Is there any
>> chance you could send a wdiff to the list, after restoring the text
>> you took out because you took out the _REQUIRED variants?
>=20
> Sure, I'm attaching a proposed patch to Autoconf master documentation =
in two forms. The first is a simple "git format-patch" file; the second =
is the output of "git diff --color=3Dalways --word-diff=3Dcolor".
>=20
>> I want it to be
>> crystal clear from the text of configure.ac that it bombed out =
because
>> package X considers 64-bit time_t and/or off_t a requirement.
>=20
> Although I don't think this feature is useful, I don't have to use it =
so we can leave it in.
>=20
> Here's why I'm not planning to use it. I help maintain (for example) =
GNU Tar, where file sizes and timestamps are crucial. But if I change =
GNU Tar to use AC_SYS_LARGEFILE_REQUIRED, people won't be able to build =
GNU Tar on ancient platforms that support file sizes only up to 2 GiB. =
Nobody will benefit from this: the very few users who'd care (computer =
museum curators, say) already know their systems are limited, and will =
simply build older versions of GNU Tar that don't use =
AC_SYS_LARGEFILE_REQUIRED, or will edit away the "_REQUIRED" before =
building. So adding the _REQUIRED will harm a very small set of users, =
will increase my maintenance burden a bit, and will benefit essentially =
nobody.
>=20
> To put it another way: we've all gotten by without needing =
AC_SYS_LARGEFILE_REQUIRED for 25 years, and there's no reason for us to =
start needing it now even though it's imperative for any serious =
application that deals with files.
>=20

I think it's useful as a primitive to have (some projects may want to =
use it to clearly define what they don't support) but I understand why =
you won't be using it for those projects.

> The situation for AC_SYS_YEAR2038_REQUIRED will likely be similar.
>=20
> As things currently stand, I plan to use AC_SYS_YEAR2038 instead of =
AC_SYS_LARGEFILE in GNU Tar and similar applications. (They'll use =
Gnulib so they'll get Autoconf 2.72-compatible AC_SYS_YEAR2038 even with =
older Autoconf.) Perhaps other maintainers will want to use the =
*_REQUIRED macros, but as far as I can see my advice will be to avoid =
them as being more trouble than they're worth.
>=20
>=20
>> I *intended* to make it clear that they are not orthogonal in
>> practice, but it is not logically necessary for them to be coupled,
>> and it is, I think, easier to understand what
>> AC_SYS_{LARGEFILE,YEAR2038} do if we document them as abstractly
>=20
> Unfortunately the documenation currently on Autoconf master makes for =
a lot of confusion and misimpression. It's more important for =
documentation to agree with what the code actually does, than for it to =
present an abstract picture of what we'd like the code to do eventually. =
The abovementioned patches fix this.
>=20

I think we might benefit from a page on the glibc wiki or something =
describing our broad vision & what distributions and upstreams need to =
know but that's not a blocker and it's a nice-to-have for the future.

I'm going to keep banging on about this topic once we've sorted out =
autoconf, so I don't think there's a risk in us forgetting about it.

>=20
>> In the new year, I can look into the possibility of decoupling the
>> macros=E2=80=99 implementations.
>=20
> I don't see how that would be possible. On the only platforms where =
--enable-year2038 matters, you cannot have year-2038 support without =
also having large-file support.
>=20
> The platforms in question are glibc 2.34+ on 32-bit ARM and x86. The =
glibc community considered making the two things orthogonal but rejected =
that alternative as being considerably more trouble than it was worth. I =
think it unlikely for other 32-bit OS suppliers to decide differently.
>=20
>=20
>> I think you=E2=80=99re still writing documentation with =
application-colored
>> glasses on, making it sound like --enable-year2038 has no negative
>> implications whatsoever.
>=20
> That's a bit unfair. The proposed documentation does mention the =
compatibility implications; it merely uses the same level of caution for =
both --enable-largefile and --enable-year2038, and it doesn't overhype =
the time_t issue with an undeserved big "Caution:" inbold.
>=20
> Although I plead guilty in being close to users (many who need year =
2038 support now for obvious reasons) I'm well aware of the implication =
for libraries. When I implemented AC_SYS_LARGEFILE back in the 1990s, =
there were similar compatibility concerns with off_t that I also took =
seriously. In the end, the need for large-file support outweighed the =
backward-compatibility hassles and AC_SYS_LARGEFILE has been a success =
in that people have used AC_SYS_LARGEFILE for years and sure there are =
occasionally glitches but the benefits far outweigh the costs.
>=20
> AC_SYS_YEAR2038 will be similar. Not identical of course, but similar. =
We've done this sort of thing before and have experience.
>=20

I agree broadly, but my concern is mainly in that until recently, most =
distributions (and upstream maintainers) were quite bad at finding out =
when ABI breaks occur. But things like libabigail's abidiff make this a =
lot easier.

Of course, the nature of ABI breakage may just mean it's a crash or =
misbehaviour which somebody never reports. But I don't want to keep =
rehashing these bits, I agree with your point below that we need to move =
forward.

>=20
>> I do not believe we have consensus
>> for AC_SYS_LARGEFILE to become a synonym for AC_SYS_YEAR2038, not =
even
>> =E2=80=9Cin a future Autoconf version.=E2=80=9D
>=20
> The proposed documentation patches contain a simple plan for how =
Autoconf can plausibly survive through the year 2038. Is there a better =
plan? If so, I'd like to hear it. If not, then let's use this plan. =
Given the long delay between Autoconf versions and end uses of =
downstream software, we need a plan now, not years from now. The plan =
doesn't have to be perfect, nor does it need to be cast in stone. But =
there needs to be a plan.

I'm happy with the patch as attached. Thank you for your perseverance. =
Unfortunately, I've been running into people who are resistant
to even fix C23 issues in configure scripts in their own code because =
"autoconf is still generating broken scripts, so I'm keen to
move past the time64/LFS blockers if we can. I think this does the job.

--Apple-Mail=_991A15E1-C762-43A1-8C6C-BDB1DC1732D1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCY69kI18UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB
NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R
kPLaAP4j8RhgT6i3OS9tZxLJ0YpxIhKz/DJ7O6HAHXjloekl/AD/R6JIKKs0YpKz
WcYbapANrN66a6pMIFnQ+hPc6O379gU=
=wBhe
-----END PGP SIGNATURE-----

--Apple-Mail=_991A15E1-C762-43A1-8C6C-BDB1DC1732D1--