Word size assumptions

[Eric S. Raymond]

I wrote:

Eric S. Raymond <esr at thyrsus.com>:
> None of this is to say that I'm not interested in embedded deployments,
> it's just that I don't think 16 bits is plausible even there anymore. not
> for anything you'd want to put NTP on. Seriously, where are there any
> 16-bit UDP stacks?  Don't just handwave, show me.

Actually it gets better than that.  The NTP Classic code didn't merely assume
32 or 64-bit ints, it assumed that your compiler supports int64_t/uint64_t.
This assumption is hard to notice because it's well-hidden - you have to
dig into the ISC library and the internals of the calendar code.

So now your bar is higher - you now need to exhibit not merely a 16-bitter
with a UDP stack, but one where the toolchain bundles arithmetic on quadwords
so neatly that you get int64_t/uint64_t as a native type. Good luck with that.

If you want to have some fun, go look at the calendar code and think about
what it would take to backport that to 16-bit hardware.  Only you might want
to have a buddy with some anti-nausea medicine and a defibrillator standing
behind you when you do this.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160923/a60fc46a/attachment.bin>