I have spoken from experience rather than from the spec. Here I am scratching my head trying to figure out why Willem and Alan are confusing 'hostid' with gethostid(), and lo and behold I see cross reference when I bother to read the man pages. Sorry.
HOWEVER: hostid != gethostid I submit to you that the inspriation for 'hostid' on Linux comes from 'hostid' on Solaris, which does NOT report something tied to the IP address (as gethostid() would). I further submit that 'hostid' on Linux does not necessarily report something tied to the IP address but rather something it gets from /etc/hostid. The CPU serial number in Sun land appears to be a 32-bit value. Although Solaris' man pages (as Linux's) cross reference 'hostid' to gethostid(), the behaviour of the former clearly indicates that it is not related to a network address but rather to the CPU identifier. Combine the flag that says "this is a Sun" with that bit string and you have something that we hope we can say is unique. The CPU serial number in IBM (zSeries) land is a 64-bit value of which we only use 24 or even 20 bits as the identification. Combine the 64-bit string with "this is an IBM mainframe" and you have something that we hope we can say is unique. Alan said: > There's really no value to hostid or gethostid() because the result is > not well-defined across platforms. ... Ignoring the gethostid() reference, I say there *is* value in 'hostid' if what you're after is a unique identifier AND IFF 1) you retool it to report something derived from the CPU ID, and 2) you take into account the vendor (to avoid collisions where both Sun and IBM happen to report CPU ID "12345"). > And I agree with Alan Cox that things like > get-me-a-world-unique-64-bit-number() should be obtained by something > other than the gethostid(). I too agree with that. > Make such a call part of the POSIX standard > or something. It's not a networking thing. gethostid(), for better or > worse, is. Right. gethostid() is a networking thing. 'hostid' is not. Dead horse?