On Mon May 16 05, Warner Losh wrote: > From: alexander <[EMAIL PROTECTED]> > 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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
