Re: [boost] Candidate for 1.66.1, if there is one

Subject: Re: [boost] Candidate for 1.66.1, if there is one
From: James E. King, III (jking_at_[hidden])
Date: 2017-12-24 16:42:24

On Sat, Dec 23, 2017 at 4:54 PM, Steven Watanabe via Boost <
boost_at_[hidden]> wrote:

> AMDG
>
> On 12/23/2017 02:25 PM, Robert Ramey via Boost wrote:
> > On 12/23/17 10:49 AM, Steven Watanabe via Boost wrote:
> >>
> >>  (We really want the format
> >> to be memorialised for all time, regardless of future
> >> changes to the test system). It should be pretty simple
> >> to set up for portable archive formats.
> >
> > Right. I'm not even sure it could be done for binary archives given the
> > evolution in compilers/libraries etc.
> >
>
>   Actually, I think you could make it work, if you
> make the key a list of the sizes of all known
> built in types + various standard typedefs
> (size_t, ptrdiff_t, streamsize).  New toolchains
> that change any of this will automatically go
> into a new bin.  We can at least guarantee that
> the archives are readable between ABI compatible
> toolchains (which is the most that we can reasonably
> expect for binary archives).
>
> >> The main problem
> >> that I see is sorting out which binary archive is for
> >> the current platform.
> >
> > since binary archives are not likely to be used for longer term storage,
> > the problem would/could be ignored for this case.  Of course someone
> > would raise the issue about using serialization to pass data on the wire
> > between different versions of the application.
> >
> > This is all quite interesting.  But I'm inclined to just accept the fact
> > that I/we can't solve every problem.  The number of cases that this
> > problem has actually occurred is pretty small, especially when
> >
> > Since I burned myself on this in a bad way in may 2010, the number of
> > cases that this problem has actually occurred is very, very small.
> > Somehow I'm thinking that it won't happen to Mr. King again at least.
> >
>
> In Christ,
> Steven Watanabe
>
>
Much of the issue I'm trying to fix could have been avoided if the
serialization
code in date_time had static assertions on the size of each field being
written.
I added that, and I recommend everyone else add the same to their
serialization
implementations.

Something interesting happened with my pull request.  On my local msvc-14.1
system I added some test checks for binary serialization of date_time.
Version
0 is 62 bytes and version 1 is 74 bytes.  12 bytes makes sense since a field
used three times was changed from boost::int32_t to boost::int64_t.  That
said,
my builds on Travis CI all failed, claiming the size is 66 and not 62!  See:

https://travis-ci.org/boostorg/date_time/jobs/320724282#L1558

This leads me to wonder if serialization is compatible across platforms and
if
it is *supposed *to be compatible across platforms.  Is this a bug??
Shouldn't
binary serialization be the same size on every platform, assuming platform-
specific types are not used?  (Maybe that's the issue, perhaps not every
type
is platform-agnostic, I wonder if date_time documentation makes any claims
to cross-platform binary serialization, or if one is supposed to use text
or xml
serialization always to achieve this).

- Jim