From owner-freebsd-hackers@FreeBSD.ORG Mon May 16 20:32:20 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 7D77D16A4D1 for ; Mon, 16 May 2005 20:32:20 +0000 (GMT) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B03E743D2F for ; Mon, 16 May 2005 20:32:19 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.3/8.13.3) with ESMTP id j4GKWFSW076969; Mon, 16 May 2005 13:32:17 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.3/8.13.3) with ESMTP id j4GKWFIp072035; Mon, 16 May 2005 13:32:15 -0700 (PDT) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.3/8.12.9/Submit) id j4GKWFqe072034; Mon, 16 May 2005 13:32:15 -0700 (PDT) (envelope-from frank) From: Frank Mayhar Message-Id: <200505162032.j4GKWFqe072034@realtime.exit.com> In-Reply-To: <20050516202029.GA21139@skatecity> To: alexander Date: Mon, 16 May 2005 13:32:15 -0700 (PDT) X-Copyright0: Copyright 2005 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL119 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Console ASCII interpretation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: frank@exit.com 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 20:32:20 -0000 alexander wrote: > You're right. The code I'm using is wrong when it is being executed > under the console. However the fact that Eterm and xterm do what I > want to do with my app show that I'm not the only one who needs a > NOP ascii value. Both render the NUL ascii code as NOP. Since both > terms are much newer than the console this indicates that they > reflect the recent changes in software development much better. I wouldn't bet that the xterm code is newer than the console code. Warner's point, that you apparently keep missing, is that, the ancient docs notwithstanding, there _is_ no hard-and-fast standard regarding how ASCII control codes are rendered. The closest thing to a "standard" there concerns BEL, HT, ESC and _possibly_ BS and NL. Everything else is pretty much up for grabs, and this quite definitely _includes_ NUL. Relying on a particular rendering of any ASCII control character across all output devices is the Wrong Thing To Do. > Keeping code simply because of historic reasons doesn't seem too obvious > to me. There are a lot if ways to let the user decide whether he > prefers historic code over new code. Hence all the COMPAT options > in the kernel. Perhaps, but this doesn't _involve_ code. This has to do with the ASCII character set and the standards, or lack thereof, that govern rendering those characters. > But it's obvious, that it would be much easier if I change my code to > only display that many bytes as I really want to be displayed. Not "much easier." "Correct." The fact that your code wrote three NULs to the console in the first place meant that your code, not the console, was broken. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/