Path: utzoo!attcan!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.unix.questions
Subject: Re: Termcap question
Keywords: termcap
Message-ID: <680@mwtech.UUCP>
Date: 1 Mar 90 10:02:46 GMT
References: <5658@star.cs.vu.nl> <671@mwtech.UUCP> <5708@star.cs.vu.nl>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 31

In article <5708@star.cs.vu.nl> gpvos@cs.vu.nl (Vos G P) writes:
[first part deleted]
>
>This introduces another problem, though. Now i can't get a \0 in my strings!
>Can someone help me with that? As no high bits are stripped, \200 gives me
>a neat \200, instead of the \0 the man pages say.

If your application does *not* strip the high order bit from the
termcap strings on output, IMHO(%) there's only one chance to output
a \0-Byte, and that chance depends on your system:
Modern TTY-Drivers often support "output translate tables" which
let the driver translate any character to any other character (or
sometimes even to a string) immediatly, before this character is
sent to the port. So, use one character you don't ever need and
translate it to \0 in the output translate tables.

(%): There is a small design flaw in termcap: The strings you
read with "tgetstr" are stored \0-terminated, as usual in C
and you only have the adress of the first character, so you can
not distinguish an 'embedded' \0 from the terminating \0. Of
course, if you are willing to write (parts of) the termcap library
functions new, you may correct this by adding a length-count ...

Another question is, why do you *need* \0-Bytes on output? I don't
know of any hardware, which requires them for a particular function
other than 'padding' and - sometimes - cursor positioning to the
left/top column/row. Padding - if required - is done by some
other mechanism in termcap and "tgoto" avoids outputing a \0-Byte
by positioning to column/row 1 and back-/upspace.
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83