Broken Date formats

On Mon, 11 Mar 2024 17:18:18 +0200
Michael S <already5chosen@yahoo.com> wrote:

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.
 
 
 
 
 

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 :(