Date: Mon, 16 May 2005 13:32:15 -0700 (PDT) From: Frank Mayhar <frank@exit.com> To: alexander <arundel@h3c.de> Cc: freebsd-hackers@freebsd.org Subject: Re: Console ASCII interpretation Message-ID: <200505162032.j4GKWFqe072034@realtime.exit.com> In-Reply-To: <20050516202029.GA21139@skatecity>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200505162032.j4GKWFqe072034>