On Mon, 11 Mar 2024 14:50:03 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On 11 Mar 2024 11:10:15 +0000 (GMT)
Theo Markettos <theom+news@chiark.greenend.org.uk> wrote:
MitchAlsup1 <mitchalsup@aol.com> wrote:
Theo Markettos wrote:
The bounds have a certain representation limits, because
they're packing 192+ bits of information into a 128 bit
space. This boils down to an alignment granularity: eg if you
allocate a (1MiB+1) byte buffer the bounds might be 1MiB+64
(or whatever, I can't remember what the rounding is at this
size). malloc() should ensure it doesn't hand out that
memory to somebody else; allocators typically do this anyway
since they use slab allocators which round up the allocation
to a certain number of slabs.
So how to you "encode" a petaByte array ?? of megaByte structs
in a capability ??
You create a capability with petabyte-scale bounds. The
precision of the bounds may be limited, which means that you
can't ram something else right up against the end or beginning
of the array if they aren't sufficiently aligned. This is in
practice not a problem: slab allocators will round up your
address before they allocate the next thing, and most OSes won't
populate the rounded up space with pages anyway.
When you take a pointer to an array element, then it has megabyte
scale bounds and they can be represented with more precision. If
your struct elements are of an arbitrary size and packed together
at the byte level then you either have to live with the bounds
giving rights to slightly more than a single struct element, or
you decide that is unacceptable and pad the struct size up to the
next representable size (just like regular non-packed structs
enforce certain alignment), and pay a small memory overhead for
that (<0.25%). That's a security decision you can make one way
or another.
Theo
Your time stamp (most likely +0000 part) confuses my Claws
Mail newsreader. I wonder if others see similar problem.
xrn on linux is not confused (which is not surprising since
linux stores time internally as GMT anyway).
Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The issue does not appear to have anything to do with OS. It's all
about parsing of 'Date' header.
For example, in your message it looks like:
Date: Mon, 11 Mar 2024 14:50:03 GMT
Claws mail understand it.
In message of Tim Rentsch it looks like:
Date: Mon, 11 Mar 2024 07:54:07 -0700
Claws mail understand it.
In my messages format is the same as in Tim's.
In messages of Theo the header looks like a mix of yours and ours:
Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The wonders of Postel's law.
On Mon, 11 Mar 2024 17:18:18 +0200
Michael S <already5chosen@yahoo.com> wrote:
xrn on linux is not confused (which is not surprising since
linux stores time internally as GMT anyway).
Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The issue does not appear to have anything to do with OS. It's all
about parsing of 'Date' header.
For example, in your message it looks like:
Date: Mon, 11 Mar 2024 14:50:03 GMT
Claws mail understand it.
In message of Tim Rentsch it looks like:
Date: Mon, 11 Mar 2024 07:54:07 -0700
Claws mail understand it.
In my messages format is the same as in Tim's.
In messages of Theo the header looks like a mix of yours and ours:
Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The wonders of Postel's law.
Another formats that Claws Mail can't handle:
Date: Thu, 18 Jan 24 09:45:05 UTC
User-Agent: Pluto/3.18 (RISC OS/5.29) NewsHound/v1.52-32
Date: Fri, 06 Oct 23 15:40:16 +0000
User-Agent: Nemo/0.999a
Date: Sun, 04 Feb 24 12:39:24 GMT
User-Agent: Newsgrouper 0.3
In all cases the badness of the header (absence of year) is rather
obvious. IMHO, such obvious cases should be rejected by news servers,
but... Postel's Law :(
Michael S <already5chosen@yahoo.com> writes:
On Mon, 11 Mar 2024 17:18:18 +0200
Michael S <already5chosen@yahoo.com> wrote:
xrn on linux is not confused (which is not surprising since
linux stores time internally as GMT anyway).
Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The issue does not appear to have anything to do with OS. It's all
about parsing of 'Date' header.
For example, in your message it looks like:
Date: Mon, 11 Mar 2024 14:50:03 GMT
Claws mail understand it.
In message of Tim Rentsch it looks like:
Date: Mon, 11 Mar 2024 07:54:07 -0700
Claws mail understand it.
In my messages format is the same as in Tim's.
In messages of Theo the header looks like a mix of yours and ours:
Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The wonders of Postel's law.
Another formats that Claws Mail can't handle:
Date: Thu, 18 Jan 24 09:45:05 UTC
User-Agent: Pluto/3.18 (RISC OS/5.29) NewsHound/v1.52-32
Date: Fri, 06 Oct 23 15:40:16 +0000
User-Agent: Nemo/0.999a
Date: Sun, 04 Feb 24 12:39:24 GMT
User-Agent: Newsgrouper 0.3
In all cases the badness of the header (absence of year) is rather
obvious. IMHO, such obvious cases should be rejected by news servers, >but... Postel's Law :(
The RFC for the date line explicitly states that the
century is derived from the YY - use the closest
century (which is good until 2050).
So claws is not RFC compliant.
On Mon, 11 Mar 2024 16:17:20 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Mon, 11 Mar 2024 17:18:18 +0200
Michael S <already5chosen@yahoo.com> wrote:
xrn on linux is not confused (which is not surprising since
linux stores time internally as GMT anyway).
Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The issue does not appear to have anything to do with OS. It's all
about parsing of 'Date' header.
For example, in your message it looks like:
Date: Mon, 11 Mar 2024 14:50:03 GMT
Claws mail understand it.
In message of Tim Rentsch it looks like:
Date: Mon, 11 Mar 2024 07:54:07 -0700
Claws mail understand it.
In my messages format is the same as in Tim's.
In messages of Theo the header looks like a mix of yours and ours:
Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The wonders of Postel's law.
Another formats that Claws Mail can't handle:
Date: Thu, 18 Jan 24 09:45:05 UTC
User-Agent: Pluto/3.18 (RISC OS/5.29) NewsHound/v1.52-32
Date: Fri, 06 Oct 23 15:40:16 +0000
User-Agent: Nemo/0.999a
Date: Sun, 04 Feb 24 12:39:24 GMT
User-Agent: Newsgrouper 0.3
In all cases the badness of the header (absence of year) is rather
obvious. IMHO, such obvious cases should be rejected by news servers,
but... Postel's Law :(
The RFC for the date line explicitly states that the
century is derived from the YY - use the closest
century (which is good until 2050).
So claws is not RFC compliant.
I didn't even pay attention that headers above contain year. Had fully >forgotten that YY format still exists.
If you're at it, how the reader is supposed to know that '18 Jan 24'
means 2024-01-18 and not 2018-01-24 ?
Michael S <already5chosen@yahoo.com> writes:
On Mon, 11 Mar 2024 16:17:20 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Mon, 11 Mar 2024 17:18:18 +0200
Michael S <already5chosen@yahoo.com> wrote:
xrn on linux is not confused (which is not surprising since
linux stores time internally as GMT anyway).
Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The issue does not appear to have anything to do with OS. It's
all about parsing of 'Date' header.
For example, in your message it looks like:
Date: Mon, 11 Mar 2024 14:50:03 GMT
Claws mail understand it.
In message of Tim Rentsch it looks like:
Date: Mon, 11 Mar 2024 07:54:07 -0700
Claws mail understand it.
In my messages format is the same as in Tim's.
In messages of Theo the header looks like a mix of yours and
ours: Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The wonders of Postel's law.
Another formats that Claws Mail can't handle:
Date: Thu, 18 Jan 24 09:45:05 UTC
User-Agent: Pluto/3.18 (RISC OS/5.29) NewsHound/v1.52-32
Date: Fri, 06 Oct 23 15:40:16 +0000
User-Agent: Nemo/0.999a
Date: Sun, 04 Feb 24 12:39:24 GMT
User-Agent: Newsgrouper 0.3
In all cases the badness of the header (absence of year) is rather
obvious. IMHO, such obvious cases should be rejected by news
servers, but... Postel's Law :(
The RFC for the date line explicitly states that the
century is derived from the YY - use the closest
century (which is good until 2050).
So claws is not RFC compliant.
I didn't even pay attention that headers above contain year. Had
fully forgotten that YY format still exists.
If you're at it, how the reader is supposed to know that '18 Jan 24'
means 2024-01-18 and not 2018-01-24 ?
RFC 1036
2.1.2. Date
The "Date" line (formerly "Posted") is the date that the message
was originally posted to the network. Its format must be acceptable
both in RFC-822 and to the getdate(3) routine that is provided
with the Usenet software. This date remains unchanged as the message
is propagated throughout the network. One format that is acceptable
to both is:
Wdy, DD Mon YY HH:MM:SS TIMEZONE
Several examples of valid dates appear in the sample message
above. Note in particular that ctime(3) format:
Wdy Mon DD HH:MM:SS YYYY
is not acceptable because it is not a valid RFC-822 date.
However, since older software still generates this format, news
implementations are encouraged to accept this format and translate
it into an acceptable format.
Granted, it is US centric. Personnaly, I prefer sortable
dates (YYYY MM DD).
On Mon, 11 Mar 2024 16:54:52 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Mon, 11 Mar 2024 16:17:20 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
Michael S <already5chosen@yahoo.com> writes:
On Mon, 11 Mar 2024 17:18:18 +0200
Michael S <already5chosen@yahoo.com> wrote:
xrn on linux is not confused (which is not surprising since
linux stores time internally as GMT anyway).
Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The issue does not appear to have anything to do with OS. It's
all about parsing of 'Date' header.
For example, in your message it looks like:
Date: Mon, 11 Mar 2024 14:50:03 GMT
Claws mail understand it.
In message of Tim Rentsch it looks like:
Date: Mon, 11 Mar 2024 07:54:07 -0700
Claws mail understand it.
In my messages format is the same as in Tim's.
In messages of Theo the header looks like a mix of yours and
ours: Date: 11 Mar 2024 11:10:15 +0000 (GMT)
The wonders of Postel's law.
Another formats that Claws Mail can't handle:
Date: Thu, 18 Jan 24 09:45:05 UTC
User-Agent: Pluto/3.18 (RISC OS/5.29) NewsHound/v1.52-32
Date: Fri, 06 Oct 23 15:40:16 +0000
User-Agent: Nemo/0.999a
Date: Sun, 04 Feb 24 12:39:24 GMT
User-Agent: Newsgrouper 0.3
In all cases the badness of the header (absence of year) is
rather obvious. IMHO, such obvious cases should be rejected by
news servers, but... Postel's Law :(
The RFC for the date line explicitly states that the
century is derived from the YY - use the closest
century (which is good until 2050).
So claws is not RFC compliant.
I didn't even pay attention that headers above contain year. Had
fully forgotten that YY format still exists.
If you're at it, how the reader is supposed to know that '18 Jan
24' means 2024-01-18 and not 2018-01-24 ?
RFC 1036
2.1.2. Date
The "Date" line (formerly "Posted") is the date that the message
was originally posted to the network. Its format must be acceptable
both in RFC-822 and to the getdate(3) routine that is provided
with the Usenet software. This date remains unchanged as the
message is propagated throughout the network. One format that is acceptable to both is:
Wdy, DD Mon YY HH:MM:SS TIMEZONE
Several examples of valid dates appear in the sample message
above. Note in particular that ctime(3) format:
Wdy Mon DD HH:MM:SS YYYY
is not acceptable because it is not a valid RFC-822 date.
However, since older software still generates this format, news
implementations are encouraged to accept this format and
translate it into an acceptable format.
Granted, it is US centric. Personnaly, I prefer sortable
dates (YYYY MM DD).
Do you want to report the bug?
If you don't, I'd try to do it myself when back at home, but you seem
to be able to do it in more authoritative manner.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 299 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 38:29:53 |
| Calls: | 6,682 |
| Files: | 12,223 |
| Messages: | 5,343,287 |