Re: Console ASCII interpretation

From: Dan Nelson (dnelson_at_allantgroup.com)
Date: 05/16/05

  • Next message: Warner Losh: "Re: Console ASCII interpretation" 
    Date: Mon, 16 May 2005 16:01:06 -0500
To: alexander <arundel@h3c.de>

    In the last episode (May 16), alexander said:
    > On Mon May 16 05, Warner Losh wrote:
    > > 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.
    >
    > OK. You defentately have a point right there. Surely telling write(2)
    > to render 4 bytes, when you only want 2 bytes to be shown is not good
    > programming style.
    >
    > On the other hand: When you're saying that NUL is != NOP then that's
    > OK. But what is == NOP. If there was a value that would do a NOP then
    > I could do that, but there isn't.

    The padding character for your current terminal type is either NUL or
    the termcap 'pc' capability, or if the 'NP' capability is set, there
    are no padding characters. Since NP is set for the cons25 termcap
    entry, if you send it a NUL, it's going to print a NUL.

    > Frankly...when I enter an ascii value directly (ALT+3-digits) the
    > console behaves differently. Because when I enter ALT+000 it DOES
    > produce a NOP. That seems a bit random to me.

    Well, that's because the code in the keyboard driver that handles the
    ALT-nnn key combo sets ks_composed_char to zero at the beginning of a
    compose sequence, and if it's still zero at the end, it assumes that
    the user hasn't done anything. I'd say that's a bug, but a
    low-priority one, since you can input a NUL via Ctrl-2 or Ctrl-Space.

    This has nothing to do with how the display driver handles NUL. 

    -- 
	Dan Nelson
	dnelson@allantgroup.com
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Warner Losh: "Re: Console ASCII interpretation"

    Relevant Pages

    • Re: Console ASCII interpretation
      ... > Subject: Console ASCII interpretation ... It means NUL. ... > react is up to them (since xterm and the console are implemented by ... > The NUL character in the ASCII character set was originally ment to ...
      (freebsd-hackers)
    • Re: Directory is a "a file system object" ?
      ... > the format is: Each file name must be terminated by a single NULL ... An additional NULL character must be appended to the end of the ... same as "%s" because a string ends at the first NUL. ...
      (microsoft.public.vc.language)
    • Re: Unicode and html - help for simple web site
      ... I suspect they relate to character encoding problems too; "non SGML character number 0" sounds like the validator had encountered the NUL character and got confused, but if I remember correctly, this cryptic message arises in different situations. ... The problem is apparently that the data comes, presumably via server-side include from an ASCII file that is converted to Unicode format too eagerly. ... If you have ASCII data to be embedded into an UTF-16 encoded document, each octet shall be followed by a zero octet. ...
      (comp.infosystems.www.authoring.html)
    • Re: fgets() and embedded null characters
      ... >:than the time it took to feed the paper up a line, so CRLF saved time. ... > margin and then print the new character at the beginning of the line. ... delay sending x (often by inserting NUL), so printing LF CR x would have ... return period when I got it wrong), there was no "flow control" on most ...
      (comp.lang.c)
    • Re: std::string question
      ... The macro 'NULL' does not refer to a character value, ... The term 'NUL' is defined by the ASCII (and perhaps ... others) character set as the value zero. ...
      (comp.lang.cpp)