Re: screen says "Bad tty" if /dev/console is a symlink
- To: firstname.lastname@example.org
- Subject: Re: screen says "Bad tty" if /dev/console is a symlink
- From: Guillem Jover <email@example.com>
- Date: Sat, 2 Feb 2013 14:04:01 +0100
- Message-id: <[🔎] 20130202130401.GB4391@gaara.hadrons.org>
- Mail-followup-to: firstname.lastname@example.org
- In-reply-to: <20130127162025.GF29258@codelibre.net>
- References: <CALL-Q8wdgX83y2dvT2PxPkb9uqt_4EnJFgGBYX0ip5=pEtLgmg@mail.gmail.com> <20130126193939.GA10063@gaara.hadrons.org> <CALL-Q8y8W8dPX45cXFEhLHrNVtNvuTv=v1kA2zjZyHLYTfnaUg@mail.gmail.com> <20130127132556.GA24172@gaara.hadrons.org> <20130127152559.GA21090@angband.pl> <20130127162025.GF29258@codelibre.net>
On Sun, 2013-01-27 at 16:20:25 +0000, Roger Leigh wrote:
> Given the amount of work already done by the Hurd porters, would
> it be viable to undef PATH_MAX and do a test build to look at how
> much this breaks? The other advantage is that it reduces duplicate
> codepaths in all the places where we have #ifdef PATH_MAX
> (where the dynamic allocation is done only for Hurd, rather than
> across the board). This alone would remove a whole bunch of
> potential bugs and improve the overall code quality and robustness.
While wearing my GNU/Hurd porter hat, I've always advocated to try to
fix MAX issues unconditionally, sometimes upstreams might prefer
different code paths though.
But yes, doing such mass build would be very useful to see how many are
still there. I'd also be in favor of removing MAX defines from all our
currently supported architectures.
Although such build would not find all MAX instances, as some upstreams
define those to arbitrary values if they are not defined.