Re: [PATCH] Cygwin: console: Ignore 0x00 on write().

[Thomas Wolff <towo at towo dot net>]

On 20.02.2020 17:04, Corinna Vinschen wrote:
> On Feb 20 23:49, Takashi Yano wrote:
> > On Thu, 20 Feb 2020 15:22:45 +0100
> > Corinna Vinschen wrote:
> > > On Feb 20 23:13, Takashi Yano wrote:
> > > > On Thu, 20 Feb 2020 14:44:59 +0100
> > > > Corinna Vinschen wrote:
> > > > > On Feb 20 14:35, Corinna Vinschen wrote:
> > > > > > On Feb 20 20:51, Takashi Yano wrote:
> > > > > > > - In xterm compatible mode, 0x00 on write() behaves incompatible
> > > > > > >    with real xterm. In xterm, 0x00 completely ignored. Therefore,
> > > > > > >    0x00 is ignored by console with this patch.
> > > > > > > ---
> > > > > > >   winsup/cygwin/fhandler_console.cc | 10 ++++++++++
> > > > > > >   1 file changed, 10 insertions(+)
> > > > > > > [...]
> > > > > > Counter-proposal:
> > > > > >
> > > > > > diff --git a/winsup/cygwin/fhandler_console.cc b/winsup/cygwin/fhandler_console.cc
> > > > > > index 66e645aa1774..1b3aa0f34aa6 100644
> > > > > > --- a/winsup/cygwin/fhandler_console.cc
> > > > > > +++ b/winsup/cygwin/fhandler_console.cc
> > > > > > [...]
> > > > > Btw., I tested this with
> > > > >
> > > > >    write (1, "A\0B\0C\0D", 7);
> > > > >
> > > > > it turned out that this results in broken output even with your patch.
> > > > > The reason is that a NUL byte must not (cannot) be evaluated by
> > > > > dev_console::str_to_con() -> sys_cp_mbstowcs().  The latter doesn't
> > > > > handle embedded NUL bytes gracefully.
> > > > Indeed. Your patch is much better.
> > > >
> > > > On Thu, 20 Feb 2020 14:35:31 +0100
> > > > Corinna Vinschen wrote:
> > > > > But, here's a question: Why do we move the cursor to the right at all?
> > > > > I assume this is compatible with legacy mode, right?
> > > > Hmm. This may be a bug of legacy console.
> > > > https://en.wikipedia.org/wiki/Null_character
> > > > says
> > > > (some terminals, however, incorrectly display it as space)
> > > >
> > > > What about ignoring NUL in legacy mode too?
> > > I'd like that, but this may be a problem in terms of backward
> > > compatibility.  The behaviour is so old, it actually precedes even the
> > > import of Cygwin code into the original CVS repository, 20 years ago...
> > If so, can't we say it is the *specification* of TERM=cygwin
> > that NUL moves the cursor right?
> Good point.  Yes, in that case it's "working as designed" and
> we just leave it as is.  I push my patch.
See `man 5 terminfo`: if NUL does anything else than just padding, the 
terminfo entry must contain a pad or npc entry, which it doesn't.
Trouble to be expected. I'd rather suggest to align the design with 
applications' expectations.