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 | a...@deuxchevaux.org (Mail) X See http://www.nonhtmlmail.org/campaign.html | a...@noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)
