From owner-freebsd-bugs Sun Jul 23 23:53:11 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id XAA05991 for bugs-outgoing; Sun, 23 Jul 1995 23:53:11 -0700 Received: from mpp.minn.net (mpp.Minn.Net [204.157.201.242]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id XAA05983 for ; Sun, 23 Jul 1995 23:53:06 -0700 Received: (from mpp@localhost) by mpp.minn.net (8.6.11/8.6.9) id BAA04722; Mon, 24 Jul 1995 01:52:41 -0500 From: Mike Pritchard Message-Id: <199507240652.BAA04722@mpp.minn.net> Subject: uname library routine (Was Re: subyte()) To: bde@zeta.org.au (Bruce Evans) Date: Mon, 24 Jul 1995 01:52:39 -0500 (CDT) Cc: freebsd-bugs@freebsd.org In-Reply-To: <199507240618.QAA04367@godzilla.zeta.org.au> from "Bruce Evans" at Jul 24, 95 04:18:30 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1493 Sender: bugs-owner@freebsd.org Precedence: bulk > >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"