> * Theo de Raadt <dera...@cvs.openbsd.org> wrote: > > First off, to get that off the plate, we don't have the POSIX, no call > > it what it is --- SVR4 -- pty stuff because it is a gigantic race. It > > was designed in response to the pty race research by Dan Bernstein, > > but the result was that the SVR4 guys still got it wrong. > > Can you please explain why. As I mentioned a long time, our > implementation on FreeBSD implements grantpt() and unlockpt() as no-ops, > which will be allowed behaviour as of the next version of POSIX. Is > FreeBSD's implementation also affected by this race? If not, why not > implement something similar for OpenBSD?
I don't see the point. > > But regarding the utmpx stuff, you've now sent us a diff which > > - writes uninitialized stack data to the file (date.c, init.c, > > perhaps more) > > No, it does not. Our implementation never writes inapplicable fields or > data past terminating null bytes of strings to disk. If you want, I can > add the memset() calls for you. So, since your library code is safe, you go and write unsafe applications, so that if anyone else copies the code and uses it somewhere else, it will cause risk. You will not add memset calls for me -- You'll add them because it is the only right programming model. > > - delete etc/ttys.pty because you don't know what it is for > > There is really no use to store pseudo-terminals in /etc/ttys, since the > utmpx implementation does not use any slot-based indexing. Apart from > utmp, I've never seen any other pieces of code that use the slot > numbering as well. What a load of bullshit. There is a need since there are old applications which still use the old way of opening ttys. > > - removes an API from libc which you have not verified > > is unused > > - crank the minor of libc, without realizing that since you have > > changed and removed interfaces, you would need to do a *major* > > bump of libc, libutil, a few X libraries, and probably 20-30 > > packages with libraries which will now detect the new interfaces > > and potentially change the behaviour. > > Well, <utmp.h> and ttyslot() have been removed, since my experience has > been that supporting both utmp and utmpx in fact causes more breakage. Not interested. > > - sneaks bits of incompatible behaviour into various programs > > (ie. last) > > Can you please clarify? As I mentioned, take into account that the patch > is not yet complete, finished, etc. I think I've said enough. > > We have a utmp which was extended a decade ago to have much longer fields. > > It works just fine. > >=20 > > I don't see what benefit the extra junk in the utmpx file provides to > > anyone. Oh, it's got a pid, so that you can send a signal to the wrong > > process... > > I'm not saying utmpx is some kind of Endl=F6sung or anything. At least > it's standardized by *something*. If there are things in your eyes wrong > with standards like POSIX, why not discuss those issues with the Austin > Group? I don't see a need in glibc compatibility.
