From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 21:01:10 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C750716A4CE for ; Mon, 16 May 2005 21:01:10 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id E209D43D76 for ; Mon, 16 May 2005 21:01:09 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j4GL16Og051377; Mon, 16 May 2005 16:01:06 -0500 (CDT) (envelope-from dan) Date: Mon, 16 May 2005 16:01:06 -0500 From: Dan Nelson To: alexander Message-ID: <20050516210105.GD85914@dan.emsphone.com> References: <20050516171143.GA19979@skatecity> <20050516.121716.41656814.imp@bsdimp.com> <20050516190113.GA20359@skatecity> <20050516.134704.78731828.imp@bsdimp.com> <20050516202029.GA21139@skatecity> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050516202029.GA21139@skatecity> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i cc: freebsd-hackers@freebsd.org Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 21:01:10 -0000 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@allantgroup.com