How big is time_t? Alignment?

[Mark Atwood]

> as long as ... I don't expect this to be a problem

I've seen it be a problem.

I recommend the following paranoia checking regarding the shm buffer:
- do not use time_t or ints directly, but cast to the "Exact width" integer
types defined in stdint.h
  see https://en.wikipedia.org/wiki/C_data_types#Fixed-width_integer_types
- add an 8 byte endian check array, cast from a int of that size, and write
in an int of the value 0x0102030405060708 or similar, to check endianness

..m


On Fri, May 13, 2016 at 3:49 AM Eric S. Raymond <esr at thyrsus.com> wrote:

> Hal Murray <hmurray at megapathdsl.net>:
> > Are we interested in any systems with 32 bit time_t?
> > Do all the systems we are interested in put 64 bit things on 8 byte
> > boundaries?
>
> All the systems we are interested in use self-alignment rules, so yes to
> the second question.
>
> If you want full details on how to compute alignment and packing, see
> http://www.catb.org/esr/structure-packing . The Linux/GCC combination
> has one odd exception to self-alignent near floats the isn't relevant here.
> There are some tricky details about trailing padding on struct members.
>
> We might be interested in supporting some 32-bit embedded systems.  As long
> as both sides of the SHM exchage were compiled 32-bit I don't expect this
> to
> be a problem.
> --
>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160514/1d0c0379/attachment.html>