Console ASCII interpretation

Dan Nelson dnelson at
Mon May 16 21:01:10 GMT 2005

In the last episode (May 16), alexander said:
> On Mon May 16 05, Warner Losh wrote:
> > The ANSI character set standard doesn't talk at all about how
> > characters are rendering.  Terminal emulation software renders the
> > characters as they see fit.  NIL is *NOT* a NOP.
> OK. You defentately have a point right there. Surely telling write(2)
> to render 4 bytes, when you only want 2 bytes to be shown is not good
> programming style.
> On the other hand: When you're saying that NUL is != NOP then that's
> OK. But what is == NOP. If there was a value that would do a NOP then
> I could do that, but there isn't.

The padding character for your current terminal type is either NUL or
the termcap 'pc' capability, or if the 'NP' capability is set, there
are no padding characters.  Since NP is set for the cons25 termcap
entry, if you send it a NUL, it's going to print a NUL.

> Frankly...when I enter an ascii value directly (ALT+3-digits) the
> console behaves differently. Because when I enter ALT+000 it DOES
> produce a NOP. That seems a bit random to me.

Well, that's because the code in the keyboard driver that handles the
ALT-nnn key combo sets ks_composed_char to zero at the beginning of a
compose sequence, and if it's still zero at the end, it assumes that
the user hasn't done anything.  I'd say that's a bug, but a
low-priority one, since you can input a NUL via Ctrl-2 or Ctrl-Space. 

This has nothing to do with how the display driver handles NUL.

	Dan Nelson
	dnelson at

More information about the freebsd-hackers mailing list