Re: Recent major number changes on ptys break grantpt() and friends in lib/libc/stdlib/grantpt.c

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.
 */
...

Cheers,
Sean