Re: [PATCH] Cygwin: dtable: Delete old kludge code for /dev/tty.

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Takashi,

On Tue, 4 Jul 2023, Takashi Yano wrote:

> On Mon, 3 Jul 2023 12:52:25 +0200
> Corinna Vinschen wrote:
> >
> > On Jun 27 22:28, Takashi Yano wrote:
> > >
> > > diff --git a/winsup/cygwin/dtable.cc b/winsup/cygwin/dtable.cc
> > > index 18e0f3097..9427e238e 100644
> > > --- a/winsup/cygwin/dtable.cc
> > > +++ b/winsup/cygwin/dtable.cc
> > > @@ -598,12 +598,7 @@ fh_alloc (path_conv& pc)
> > >  	  fh = cnew (fhandler_mqueue);
> > >  	  break;
> > >  	case FH_TTY:
> > > -	  if (!pc.isopen ())
> > > -	    {
> > > -	      fhraw = cnew_no_ctor (fhandler_console, -1);
> > > -	      debug_printf ("not called from open for /dev/tty");
> > > -	    }
> >
> > This is ok-ish.  The problem is that the original patch 23771fa1f7028
> > does not explain *why* it assigned a console fhandler if the file is not
> > open.  Given that, it's not clear what side-effects we might encounter
> > if we change this.  Do you understand the situation here can you explain
> > why dropping this kludge will do the right thing now?  If so, it would
> > be great to have a good description of the original idea behind the
> > code and why we don't need it anymore in the commit message.
>
> I am not really sure the reason why the kludge code was needed.
> However, I noticed stat() fails before the commit 6ae28c22639d
> without the kludge code if the program calls setsid(). After the
> commit 6ae28c22639d, this does not happen. Therefore, I think
> this kludge code is no longer necessary.

FWIW this is the exact kind of issue I keep pointing out with these commit
messages.

It is quite often totally unclear what the issues are, there are sometimes
links to threads where one could potentially go and hunt and guess what
the outcome of that discussion was.

And more often than not, these commit messages talk vaguely about "This
fixes the issue by dropping a kludge" or something similar, instead of
giving a clear and comprehensive description as to what the problem is,
why the code was faulty, what is done instead, and what alternatives were
considered and the reasons why they were rejected.

This leaves a lot of room for improvement without which we're prone to
repeat these increasingly frustrating exchanges.

Once again, I would highly recommend to read
https://github.blog/2022-06-30-write-better-commits-build-better-projects/
and craft commit messages based on the provided guidance. I promise you
that you will no longer have to say "I am not really sure the reason why
the kludge code was needed", like, ever again, if you follow that
article's advice.

Ciao,
Johannes