<div dir="ltr"><div>Ok, sigh, since we can't change the struct, we will live with it.<br><br></div><div>It may still make sense to do some int width and endian sanity testing.<br><br></div><div>And we can push changes to ntpsec and gpsd to use exact width integer types.<br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, May 13, 2016 at 8:18 PM Hal Murray <<a href="mailto:hmurray@megapathdsl.net">hmurray@megapathdsl.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<a href="mailto:fallenpegasus@gmail.com" target="_blank">fallenpegasus@gmail.com</a> said:<br>
> I recommend the following paranoia checking regarding the shm buffer: - do<br>
> not use time_t or ints directly, but cast to the "Exact width" integer types<br>
> defined in stdint.h<br>
>   see <a href="https://en.wikipedia.org/wiki/C_data_types#Fixed-width_integer_types" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/C_data_types#Fixed-width_integer_types</a> -<br>
> add an 8 byte endian check array, cast from a int of that size, and write in<br>
> an int of the value 0x0102030405060708 or similar, to check endianness<br>
<br>
That would make sense if we were starting from scratch.<br>
<br>
The current status is that NTP Classic, NTPsec, and gpsd all use the same<br>
text to define the struct used in shared memory.  I don't think we should<br>
rock that boat.  This is by definition the way to do it, whatever the memory<br>
layout turns out to be.<br>
<br>
<br>
<br>
--<br>
These are my opinions.  I hate spam.<br>
<br>
<br>
<br>
</blockquote></div>