Console ASCII interpretation

[alexander]

On Mon May 16 05, Warner Losh wrote:
> From: alexander <arundel at h3c.de>
> Subject: Console ASCII interpretation
> Date: Mon, 16 May 2005 19:11:44 +0200
> 
> No.  It means NUL.  When writing with write(2), you are telling the
> system to output 4 bytes.  How different terminal emulation programs
> react is up to them (since xterm and the console are implemented by
> different sets of code).
> 
> Warner

Surely the implementation is up to the terminal itself, but what's the use of
a STANDARD, if it isn't standarized? I found this little explanation:

> 0 -- NUL -- Null character
> The NUL character in the ASCII character set was originally ment to
> be treated as a NOP, a character to be ignored. This would be useful
> on paper tapes where additional information had to be added in between
> existing information. However, some printing devices had the NUL implemented
> as a wite space instead. Later on, the importance of the null character
> increased significantly when it was defined as the string terminator in
> the C programming language. It made it possible to define strings of
> infinite length in programming languages. Until then most languages like
> Pascal defined a string as a length indicator, followed by an array that
> contained the characters.

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.

Cheers.