Console ASCII interpretation

[Frank Mayhar]

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 at exit.com	http://www.exit.com/
Exit Consulting                 http://www.gpsclock.com/
                                http://www.exit.com/blog/frank/