From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4219 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: request: increase TTY_NAME_MAX in limits.h Date: Sat, 9 Nov 2013 12:38:42 -0500 Message-ID: <20131109173842.GI24286@brightrain.aerifal.cx> References: <527E1774.4060305@skarnet.org> <20131109163603.GG24286@brightrain.aerifal.cx> <527E6EE3.2050109@skarnet.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1384018733 5867 80.91.229.3 (9 Nov 2013 17:38:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Nov 2013 17:38:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4223-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 09 18:38:59 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VfCUq-0005UK-Es for gllmg-musl@plane.gmane.org; Sat, 09 Nov 2013 18:38:56 +0100 Original-Received: (qmail 19825 invoked by uid 550); 9 Nov 2013 17:38:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 19814 invoked from network); 9 Nov 2013 17:38:55 -0000 Content-Disposition: inline In-Reply-To: <527E6EE3.2050109@skarnet.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4219 Archived-At: On Sat, Nov 09, 2013 at 05:20:35PM +0000, Laurent Bercot wrote: > > >If we change it I think we might as well go with the glibc value of 32 > >rather than just increasing it by 4. > > That would be great, thanks :) > > I'm honestly surprised that those buffers are so small, even in glibc. > Sure, it takes up static space, and in practice a small value works for > most people since it will usually be /dev/something, but since ttyname() > is not supposed to ever fail with ERANGE or any kind of overflow, I was > expecting the buffer to be PATH_MAX bytes. Or even dynamically (re)allocated - > which would pull in malloc(), but text space + a bit of heap space is cheaper > than static space. I'm not sure exactly what glibc does; technically, there's no reason the size of this internal buffer needs to match TTY_NAME_MAX. I just chose that as a natural size for it. On most systems, where the ttyname is /dev/xxxxx or /dev/pts/xxxxx, 20 should be sufficient and 32 should leave plenty room. Your situation is a bit odd but there's no sense in gratuitously breaking it. Rich