Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Fwd: 64-bit time_t transition for 32-bit archs: a proposal
(Russ Allbery)
2. Re: Fwd: 64-bit time_t transition for 32-bit archs: a
proposal (Julien ?LIE)
3. Re: Fwd: 64-bit time_t transition for 32-bit archs: a
proposal (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Mon, 26 Jun 2023 11:59:27 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Cc: Olaf Titz <[email protected]>
Subject: Fwd: 64-bit time_t transition for 32-bit archs: a proposal
Message-ID: <[email protected]>
Content-Type: text/plain
Forwarding this discussion from debian-devel about 64-bit time_t migration
to inn-workers since this is a better place to discuss the details.
To: [email protected]
Subject: Re: 64-bit time_t transition for 32-bit archs: a proposal
From: Olaf Titz <[email protected]>
Date: Mon, 26 Jun 2023 20:08:50 +0200
> > Oh, wait! No, I'm wrong, CNFS actually does something smart and encodes
> > the header in ASCII when writing it to disk.
> >
> > Okay, phew, this isn't going to be nearly as bad as I had thought.
>
> Good news. It would be great if you could add relevant info to the wiki page:
> https://wiki.debian.org/ReleaseGoals/64bit-time#Known_Issues
That page now says
< The CNFS storage format does not have problems with its disk format,
< but the less-used timecaf storage format might (yet to be confirmed).
Yes, timecaf does have a problem, two actually.
1. The CF file header contains a field time_t LastCleaned. Changing
sizeof(time_t) will change sizeof(CAFHEADER) and make existing CF file
unreadable with newly compiled code.
AFAICT that field is only written once and never read, so it could be
patched out, but that requires some care.
2. The CF files use file names like timecaf-nn/bb/aacc.CF where nn is
the storage class and aabbccxx the time of arrival, changing the file
name in 256-second intervals. The code using %02x format strings to
determine the file name, and everything else checking them for
validity, will have to be changed appropriately.
Olaf
------------------------------
Message: 2
Date: Mon, 26 Jun 2023 22:54:05 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Cc: Olaf Titz <[email protected]>
Subject: Re: Fwd: 64-bit time_t transition for 32-bit archs: a
proposal
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
> Forwarding this discussion from debian-devel about 64-bit time_t migration
> to inn-workers since this is a better place to discuss the details.
Thanks for the forward!
Aren't there caveats with printf()-like calls or atol()-like calls?
We often have casts of time_t variables to "%lu" or "%ld" in printf().
Do they work fine on both 32-bit and 64-bit architectures with a 64-bit
time_t after 2038?
Example in innd/site.c:
snprintf(pbuff, sizeof(pbuff), "%ld", (long) Data->Arrived);
In expire/makehistory.c, we have:
arrived = (time_t) atol(p);
Wouldn't atoll(p) be needed in some cases?
(We're also reading the epoch times in active.times with an atol() call
in nnrpd/commands.c.)
> Yes, timecaf does have a problem, two actually.
[...]> 2. The CF files use file names like timecaf-nn/bb/aacc.CF where nn is
> the storage class and aabbccxx the time of arrival, changing the file
> name in 256-second intervals. The code using %02x format strings to
> determine the file name, and everything else checking them for
> validity, will have to be changed appropriately.
The storage tokens in history should also be changed accordingly.
They contain the same "aabbcc":
@04nn00aabbccyyyyxxxx0000000000000000@
Same thing for timehash:
@02nnaabbccddyyyy00000000000000000000@
"aabbccdd" is the arrival time in hexadecimal, and "yyyy" a sequence number.
Hopefully we have zeroes to re-use in the token for the larger arrival
time size, and an history rebuild will do the job.
--
Julien ?LIE
??Ce qu'on est arriv? ? faire avec le t?l?phone sans fil, va-t-on le
r?ussir un jour avec les haricots???? (Philip Geluck)
------------------------------
Message: 3
Date: Mon, 26 Jun 2023 14:59:17 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Fwd: 64-bit time_t transition for 32-bit archs: a
proposal
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Aren't there caveats with printf()-like calls or atol()-like calls?
> We often have casts of time_t variables to "%lu" or "%ld" in printf(). Do
> they work fine on both 32-bit and 64-bit architectures with a 64-bit
> time_t after 2038?
> Example in innd/site.c:
> snprintf(pbuff, sizeof(pbuff), "%ld", (long) Data->Arrived);
> In expire/makehistory.c, we have:
> arrived = (time_t) atol(p);
> Wouldn't atoll(p) be needed in some cases?
> (We're also reading the epoch times in active.times with an atol() call in
> nnrpd/commands.c.)
Yes, I think you're right; those need to become long long (although
unsigned long buys another decade or so).
It's not yet clear whether Debian will try to convert the i386
architecture to 64-bit time_t, drop it, or do something else with it.
There's a large debate right now in the Linux world over whether i386 is
more useful as a legacy build to run old software (which will never be
able to use 64-bit time_t), or as a platform for running current software.
It's fairly hard to find new 32-bit-only x86 processors these days, and
even the large numbers of legacy systems out there are getting pretty old.
But this will come up for other architectures even if i386 doesn't convert
(ARM, for instance, and there's probably at least one person out there
running INN on an ARM Linux system).
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 151, Issue 1
*******************************************
