Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Mar 2005 15:10:21 -0500
From:      Brian Fundakowski Feldman <green@freebsd.org>
To:        Sean McNeil <sean@mcneil.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Recent major number changes on ptys break grantpt() and friends in lib/libc/stdlib/grantpt.c
Message-ID:  <20050304201020.GH6011@green.homeunix.org>
In-Reply-To: <1109960265.7962.4.camel@server.mcneil.com>
References:  <20050303021608.1BB663284@mx2.synetsystems.com> <20050304144415.GE6011@green.homeunix.org> <1109960265.7962.4.camel@server.mcneil.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 04, 2005 at 10:17:45AM -0800, Sean McNeil wrote:
> On Fri, 2005-03-04 at 09:44 -0500, Brian Fundakowski Feldman wrote:
> > On Wed, Mar 02, 2005 at 07:39:09PM -0600, Richard Todd wrote:
> > > I managed to work around the immediate problem and stop my script from 
> > > complaining by bludgeoning the p5-IO-Tty Makefile.PL with a blunt instrument
> > > to make it think this system didn't support grantpt() etc. (causing the module
> > > to fall back to other methods of dealing with ptys).  The proper fix for
> > > grantpt.c is less clear, though.  Changing it to figure the proper pty 
> > > major number by stating a known pty node (say, /dev/ptyp0) would work, but from
> > > what I understand that's going to break when phk commits his forthcoming
> > > patch which will make the whole concept of major numbers go away. Any ideas?
> > 
> > Just remove all knowledge of device majors/minors from the module.  Why
> > should it care?  All it could possibly do with that information is
> > sanity-check that the device name (that it already knows how to generate)
> > isn't somehow replaced with something else.
> 
> This isn't a module, this is a libc function.  It seems like you have
> some ideas how this can be fixed, so does that mean you are volunteering
> to do so?  Or does someone else already claim responsibility for this
> part of libc?
> 
> You are correct about it being a sanity check.  The comment makes that
> clear.  Worst case it could just be pulled out:
> 
> /*
>  * ISPTM(x) returns 0 for struct stat x if x is not a pty master.
>  * The bounds checking may be unnecessary but it does eliminate doubt.
>  */
> ...

Whether you want to call libc a module or not, sure, I'll fix it ;)
It indeed should be pulled out.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green@FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050304201020.GH6011>