Date: Mon, 24 Jul 1995 01:52:39 -0500 (CDT) From: Mike Pritchard <mpp@mpp.minn.net> To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-bugs@freebsd.org Subject: uname library routine (Was Re: subyte()) Message-ID: <199507240652.BAA04722@mpp.minn.net> In-Reply-To: <199507240618.QAA04367@godzilla.zeta.org.au> from "Bruce Evans" at Jul 24, 95 04:18:30 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >I was looking into PR# 462 (uname system call doesn't return > >uts.version), and it appears to me that the problem is that > >the subyte() routine isn't writing the bytes back to the > >correct address in the caller's memory. Subyte() isn't > >called in very many places, so it is possible that > >it has been broken for a while and no one would have > >ever really noticed. > > It is called a lot for tty input via ureadc(). > > >Could someone go double check me on this and make sure > >I'm not hallucinating about this? > > The uname() in kern_xxx.c is a mirage. It is now only for > compatibility. uname() is now implemented in the library > by calling sysctl() for each component. > > There is also compatibility cruft for a the BSDI uname(). Aha! No wonder it looked like the kernel subyte() call was not returning the correct information, it wasn't, because it was never being called! After fiddling with the libc uname() routine, I found that the version doesn't get returned because it is too big to fit into the 32 character string in the version field of the utsname structure. Should the uname libc routine be hacked to read the version into a different (larger buffer) and then copy just some of that information back into the utsname.version field? Maybe search for the first ":" and truncate it there (sort of like what the kernel uname() routine is doing)? -- Mike Pritchard mpp@mpp.minn.net "Go that way. Really fast. If something gets in your way, turn"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507240652.BAA04722>