Re: Query about uname.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rob,

On Thu, Nov 27, 2008 at 8:35 AM, Rob Landley <rob@xxxxxxxxxxx> wrote:
> http://kernel.org/doc/man-pages/online/pages/man2/uname.2.html
>
> It says the length of the fields was unspecified.

Yup -- that's what POSIX says.

> Initially I thought that
> meant it was implemented as each field starting right after the previous one's
> null terminator,

(Not sure why you would assume that.)

> but it turns out that each field is exactly 65 characters
> long.

Well, yes.  That info is lower down in the page:

       Over  time, increases in the size of the utsname structure have
       led to three successive  versions  of  uname():  sys_olduname()
       (slot  __NR_oldolduname), sys_uname() (slot __NR_olduname), and
       sys_newuname() (slot __NR_uname).  The first one used length  9
       for  all fields; the second used 65; the third also uses 65 but
       adds the domainname field.  The glibc uname() wrapper  function
       hides these details from applications, invoking the most recent
       version of the system call provided by the kernel.

> This is hardwired into both bits/utsname.h and linux/utsname.h, and more to
> the point you can't talk to the kernel without knowing what this value _is_,

Why do you claim this?  As noted in the first para of the description,
the fields of the structure are null-terminated, which, in the typical
case, makes it quite possible to use them without knowing their
(maximum) lengths.  And indeed, a portable program should not care.

> so leaving it unspecified is silly.  It's part of the current kernel's binary
> abi, and the value is currently 65.

And that last piece is exactly part of the problem, because once upon
a time (okay: a long time ago, now), it was true that "the value is
currently 9".

It seems to me that all the info you needed was there in the page, but
you didn't read the whole page.  The question is, whether the page
could/should provide more clues to make sure that the reader is
pointed to the fine details (which, for the reasons I described above,
are often not needed).

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux