Re: [ntp:questions] Ntpd in uninterruptible sleep?

[Dave Hart <hart%ntp.org@localhost>]

On Thu, Nov 17, 2011 at 17:57, Dave Hart <hart%ntp.org@localhost> wrote:
> On Thu, Nov 17, 2011 at 17:19, Martin Husemann <martin%duskware.de@localhost> 
> wrote:
>> On Thu, Nov 17, 2011 at 05:14:33PM +0000, Dave Hart wrote:
>>> NTP_INSIST() always generates code, even if you build without DEBUG
>>> (using configure option --disable-debugging).
>>
>> Ok, I don't see how the loop could be infinite then...
>>
>>> Impressive.  Was this with "%.2f"?
>>
>> Yes, actual test program attached. It has been running on a sparc64 machine
>> for several hours now, I'll run it on a 32bit sparc over night as well.
>
> Nice code.  After reading a grad student's barey-indented code
> littered with strcpy() and strcat() (associated with a paper sent to
> the LinuxPPS mailing list) overnight, it was refreshing to see
> evidence of competence.  I might have used sizeof() instead of 1000,
> but this code doesn't need such future-proofing.  My fingers are
> crossed hoping one of those machines will end up with a very warm CPU.

I intended to make one more comment.  I have seen rand()
implementations that only provide 16 bits of entropy (in one of
Microsoft's earliest 32-bit C runtimes, circa 1992 when I was a
developer working on the NT security development team, and I was
generating GUID-like SID prefixes for the SAM database at NT
installation time), so I'm still in the habit of calling rand() twice:

uint32_t noise = (rand() << 16) ^ rand();

I doubt that's needed for NetBSD's rand(), though.  The 16-bit
implementation I saw was probably simply a holdover from a C runtime
that was shipping with 16-bit int C compilers recently ported to
32-bit.  Nonetheless, I used the idiom above several times recently in
ntpd, figuring the extra cost was worthwhile insurance against crap
runtimes one might find on, for example, embedded platforms where ntpd
has been known to be used.

Cheers,
Dave Hart