Re: [screen-devel] Remarks on the patch for long login names (was: Re: GNU Screen v.4.2.0)

[Axel Beckert]

Hi Amadeusz,

On Tue, Apr 22, 2014 at 06:32:07PM +0200, Amadeusz Sławiński wrote:
> > * 32 seems a little bit short to me. Why not use what the system
> >   provides? According to https://bugs.debian.org/560231 at least on
> >   Linux there is LOGIN_NAME_MAX defined in
> >   /usr/include/bits/local_lim.h which seems to default to 256
> >   nowadays. I think screen should support at least that on Linux then,
> >   too.
> > 
> 
> Ah, I based my value on utmp entries
> bits/utmp.h:#define UT_NAMESIZE 32
> bits/utmp.h:  char ut_user[UT_NAMESIZE];        /* Username.  */
> bits/utmpx.h:#define __UT_NAMESIZE      32
> bits/utmpx.h:  char ut_user[__UT_NAMESIZE];     /* Username.  */

Interesting that there are different values for that kind of data
around on the same kind of system. :-)

> Well, let's just use 256, it will probably allow for use with most
> crazy login schemes.

... at least for the next few decades. ;-)

> >   I hence propose to check if LOGIN_NAME_MAX is defined and if so, use
> >   that, otherwise use a fixed value, maybe 32 to be on the save side
> >   for ancient OS. The patch proposed in
> >   https://lists.gnu.org/archive/html/screen-devel/2011-05/msg00000.html
> >   (see also below) proposed to use 50, but I prefer numbers which are
> >   powers of two. (Debian uses 50 currently, too, though.)
> 
> In previous mail Jürgen suggested that it's bad idea to have build time
> changing defines in struct msg.

Ah, right, we should care about the MSG_VERSION bump. Good point!

Then again, this also means that this change will need a MSG_VERSION,
right? Which again is probably a bad thing to do in a
micro-/bugfix-update (i.e. just incrementing the last number of the
version). Humm. Sounds like a small dilemma to be, as I'd be happy to
see that change in Screen soon, too.

According to Semantic Versioning (see http://semver.org/),
non-backwards-compatible (i.e. API) changes validate respectively
require a bump of the major number -- which is not what is planned to
do in the screen-v4 branch. :-/

And no, I don't urge you to use Semantic Versioning as defined on
http://semver.org/. I just thought about what version number a new
release with MSG_VERSION bump should have and semver.org is always a
nice place to compare with. In Semantic Versioning I miss the notion
of large user-visible changes which are more than just
backwards-incompatible API changes. Maybe my semantics are on a
different axis...

> I will hardcode them.

Fine for me, if they are that large. :-)

JFTR: Debian currently uses 40 characters for the TERM length (i.e.
doubled the old value), but the case reported in Debian should also
works with 32 characters: "rxvt-unicode-256color" (21 characters, also
reported at Savannah at https://savannah.gnu.org/bugs/?30880)

So I consider 32 characters as "probably large enough for now".

> >   That last line needs to be changed to 32 (or LOGIN_NAME_MAX or
> >   MAX_USERNAME_LEN or whatever), too, because the whole #ifdef reads
> >   as follows:
> 
> Yes, thanks for checking.

Thanks for caring!

With your last commit I can already drop two patches of the Debian
package. Yay! :-)

But I'm looking forward to 4.2.1 anyway, independent of a MSG_VERSION
bump or not. :-)

                Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | address@hidden  (Mail)
 X   See http://www.nonhtmlmail.org/campaign.html | address@hidden (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)