<Deuce> Easiest fix would be to have outbuf_append adjust outlen to be "long enough" if doubling isn't.
<Deuce>         /* Not enough room, double the size. */
<Deuce>         *outlen *= 2;
<Deuce>         if(*outp - *outbuf + len >= *outlen)
<Deuce>                 *outlen = *outp - *outbuf + len + 1
<Deuce> So yeah, blindly doubling won't work for utf-8.
<Deuce> Because a line will have more bytes than the number of characters in a line.

cvstat.

Per RFC-5198:
   2.  In Net-ASCII, CR MUST NOT appear except when immediately followed
       by either NUL or LF, with the latter (CR LF) designating the "new
       line" function.  Today and as specified above, CR should
       generally appear only when followed by LF.  Because page layout
       is better done in other ways, because NUL has a special
       interpretation in some programming languages, and to avoid other
       types of confusion, CR NUL should preferably be avoided as
       specified above.

It's not worth breaking all connections for some broken telnet servers.
Especially since we do not explicitly want CR behaviour which is the only
place it's allowed.

Per RFC-854:
   the sequence "CR NUL" must be used where a carriage return alone is
   actually desired;

It's quite possible that these "telnet servers" are actually raw socket
servers and should use raw sockets rather than telnet.

Note that conn_pty does not support PETSCII or ATASCII as the terminal
type since it sets TERMCAP, and I don't have a termcap entry for either of
those.

rather than no char, when calculating word lengths. We needed that 'continue'
here.

on cterm.

codes.

I like the -W @-code format modifier better for "WIDE" than for "WRAP" (no
body is using -W yet, right?) - so, change wrap to "->" and double-wide to
"-W".

terminal "type" string (ANSI, RIP, PETSCII, or DUMB).
Expose this value in JS via the new console.type read-only property.
The TERM @-code now expands to this string rather than the (often
client-supplied) sbbs_t.terminal string value.

dereference. (found by Coverity)

Expression syntax in function unicode_to_cp437
:-(

I took a short-cut with some of the names - TODO: fix. <sigh>

(e.g. "@code:BIG-RED@", the argument would get chopped to just "BIG")
so don't support format modifiers when a ':' is present in the @-code.

When appended to an @-code, displays it double-wide using "fullwidth" Unicode
code points if possible, spaces between the characters otherwise.

The pipe char is problematic to discuss in msg bases and on the Wiki. <shrug>

Create a sbbs_t method: wide(), which displays a string using "fullwidth"
Unicode characters, when possible, otherwise, double-spaced.
Exposed in JS via console.wide() and a new @-code: WIDE:<string>

unicode_width() now correctly returns 2 for the CJK and other code points that
are typically displayed in 2 columns with non-proportional fonts.

Mainly, for the purpose of determing which code points represent "fullwidth"
(2 column) characters.

VS: ----------------------------------------------------------------------

(currently).
Created for use with the EnterYourBirthday text.dat string, so the CHECKMARK
@-code can be used as well. @-codes can't be used in strings with
printf-specifiers (e.g. %s).

square root symbol (or PETSCII check mark), as appropriate.

with UNICODE_*

enumeration value '...' not handled in switch

in unicode_width().

<Deuce> Unicode isn't encoding.
<Deuce> And petdefs.h is a mapping.
:-)

@U+<codepoint-in-hex>@ - automatic CP437 fallback char, if available
@U+<codepoint-in-hex|cp437char-in-hex>, specify CP437 fallback char
@U+<codepoint-in-hex!cp437char-in-hex>, specify CP437 fallback char
(used if no automatic fallback mapping is available)

Replaced unicode_is_zerowidth() with unicode_width(), in preparation for
"fullwidth" char support.
Added UNICODE_UNDEFINED definition (0x0000)
(UNICODE_NULL is already defined, at least in MSVC).