New ntpq peers chops refclocks to 6 characters

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> But there is lots more room in that column.  I think it will hold a worst 
> case IPv4 numerical address.
> 
> 
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  HP5850          .GPS.            0 l    7   64    1    0.000    0.000   0.000
>  PPS(0)          .PPS.            0 l    -   64    0    0.000    0.000   0.000
>  SHM(0)          .SHM.            0 l    5   64    1    0.000  -218.14   0.001
>  SHM(1)          .SHM.            0 l    4   64    1    0.000   -1.094   0.001
>  GPSD(0          .GPSD.           0 l    3   64    1    0.000  -308.94   0.001
>  GPSD(1          .GPSD.           0 l    2   64    1    0.000   -0.209   0.001

Hmmm.  I think the client-side code is computing an incorrectly short field
width. That shouldn't be hard to fix if I can reproduce this. What set of
options produces it?

Let me explain how the behavior has changed.

What ntpq used to do is detect that a peer it's querying is a clock by
looking at its IP address (127.127.t.u), and call a routine that looks
in a table for the driver shortname based on the t field.

But I hated those magic addresses and the exposed numeric driver types,
so I got rid of them.  Instead, in response to a peer query ntpd may
send back a variable 'displayname' - will if the peer is a clock. If
ntpq sees 'displayname' in the response it treats that value as an override
for the first column.  IOW, ntpd is now responsible for telling ntpq how
a peer line should be labeled.  

It looks like displayname is being received correctly, then truncated
by the display code.  There's some logic for computing the shortest
possible first-column width to hold all the labels from a
peer-response set that looked fishy and overcomplicated to me when I
first saw it; I think your bug means my change made it lose its marbles
and am less surprised at this than I might be.

(Note: Classic's ntpq will just keep doing what it has always done. The
only case that degrades a little is our ntpq querying a Classic ntpd -
our display logic will fail to recognize that 127.127.t.u is a clock.
But that's not a big deal given there'll be a clock refid in the next
column.)

I can probably fix your bug by removing some dodgy code.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>