Date: Mon, 16 May 2005 13:47:04 -0600 (MDT) From: Warner Losh <imp@bsdimp.com> To: arundel@h3c.de Cc: freebsd-hackers@freebsd.org Subject: Re: Console ASCII interpretation Message-ID: <20050516.134704.78731828.imp@bsdimp.com> In-Reply-To: <20050516190113.GA20359@skatecity> References: <20050516171143.GA19979@skatecity> <20050516.121716.41656814.imp@bsdimp.com> <20050516190113.GA20359@skatecity>
next in thread | previous in thread | raw e-mail | index | archive | help
> Since there already is an ascii code for the white space (SP = 20h) I don't > quite understand why 00h is also interpreted as a white space. Because that > makes two values for a white space, but not a single value for the NOP > operator. If this behaviour of the console is due to historic reasons > (old BSD or AT&T Unix) then there should be a way of changing the code. 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. While the ansi standard suggests that, it isn't required to be. It is used for a variety of thing in a variety of places. Some terminals use it as a timing character to give other operations a chance to finish. Some terminals even use it to specify coordinates because their command set is binary in nature. In addtion, many terminal emulators will pass through characters that don't enter a meta mode unmolested. In this pass through, often times the default rendering for a character that is not otherwise present in the font is ' '. Sometimes another character is chosen (like a square box, a 1/2 tone triangle, a cursor outline rectangle, etc). That's just part of the game. You could argue that DEL is used to rubout (delete backwards character) a character, why then would you have BS (back space) do the same thing? (please don't argue, since both are right or wrong depending on the context). The point is that control sequences in ASCII aren't well standardized, and even if the original standards documents appear to say otherwise, time has shown a huge variety of implementations out there. You are running into one right now. You are output 4 bytes, when you should only be outputting 2 and are claiming that the bug is shomehow in the console software. Yet the console software is emulating something older with a high degree of fidelity. Were we to change today's implementation, there's code that's been written over time that depends on the current behavior. Maybe not much code, and one could argue that there are bugs in that code. But maybe a bunch of code... I guess what I'm trying to say is that if you output NUL, then you are telling the terminal emulation to do something. Don't be surprised when it does do something :-). The bottom line is that your code is wrong, and your understanding of NUL in this context is wrong and you need to fix both. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050516.134704.78731828.imp>