When calling PR_GetSystemInfo() on mac with PR_SI_HOSTNAME to get the hostname, it only returns the first octet. For example, you get "208" instead of "208.12.38.206". This is because PR_GetSystemInfo truncates the string that it gets back from _PR_MD_GETHOSTNAME (the ip address) at the first period.

PR_GetSystemInfo(PR_SI_HOSTNAME) is supposed to return the host name. For example, the host name for "warp.mcom.com" is "warp". This is why it truncates the string that it gets back from _PR_MD_GETHOSTNAME at the first period. There are two different problems here. 1. The Mac implementation of _PR_MD_GETHOSTNAME should not return the IP address. Do you know how to get the host name on the Mac? 2. If you want the IP address of the local host, PR_GetSystemInfo(PR_SI_HOSTNAME) is not the right function to call. NSPR does not have a function that returns the IP address of the local host and in fact it is rather tricky to do that.

wtc: To get the ip address, we take that hostname and do a reverse lookup. Its not perfect, but its what ns4 did, I believe. (This is needed for proxy autoconfig, which has a variable the script can look at to get the current ip address). It fails in machines with multiple ip's, but its still better than nothing, in most cases. I believe that this variable was added to the public API in ns2.x, so we can't change it now. See bug 83063.

Err, bug 80363, rather.

...and the component is set to Networking:Cache because...

This should be an NSPR bug.

-> NSPR

*** Bug 147940 has been marked as a duplicate of this bug. ***

> 1. The Mac implementation of _PR_MD_GETHOSTNAME should not > return the IP address. Do you know how to get the host name > on the Mac? Comments in the current implementation suggest that the Mac does not _have_ an Internet hostname (which sounds plausible to me as a Mac user: certainly in OS 9 there is no way to set it), so they are falling back on using the IP address in string form as being functionally equivalent. The obvious solution to this bug is to take the little bit of code that converts the fully qualified hostname into an unqualified hostname and add #ifndef XP_MAC ... #endif around it, since it's an invalid thing to do to an IP address used in lieu of a hostname. This is an 5-minute fix, and I'm a little puzzled why this bug is 10 months old. > 2. If you want the IP address of the local host, > PR_GetSystemInfo(PR_SI_HOSTNAME) is not the right function > to call. NSPR does not have a function that returns the > IP address of the local host and in fact it is rather tricky > to do that. For my purpose (generating a globally uniqui identifier string) either a fully qualified hostname or an IP address is fine. But I'd really prefer "warp.mcom.com" to just "warp" on non-Mac platforms (after all, there are a lot of machines in the worls called "www"), and I'd certainly prefer "208.12.38.206" to just "208" on Mac. > PR_GetSystemInfo(PR_SI_HOSTNAME) is supposed to return the > host name. For example, the host name for "warp.mcom.com" > is "warp". There are applications (like mine) for which the fully qualified hostname is more useful. Maybe you should add another enum value, PR_SI_FULLHOSTNAME which returns the fully qualified hostname. Then on Mac PR_SI_FULLHOSTNAME and PR_SI_HOSTNAME would give the same result (the IP address), but on other platforms they would give the unqualified hostname "warp" and the fully qualified one "warp.mcom.com" respectively. ---- WORKAROUND ---- Until this bug gets fixed, there is a dirty hack workaround. What NSPR actually returns in the buffer is '208\012.38.206\0' (on Mac) or 'warp\0mcom.com\0' (on other platforms), since it first gets the IP address/fully qualified name and then truncates it. By converting the first '\0' back into a '.' you can recover the information that it unhelpfully threw away. (Obviously this needs to be done with caution: if the second '\0' were not there for some reason, you would have an unterminated C string, and any code that does this should bear in mind the possibility that this bug might one day get fixed.)

Roger, you are right. Thanks for investigating this bug and suggesting a fix. This patch is the obvious solution that you suggested.

The patch has been checked into the tip and NSPRPUB_PRE_4_2_CLIENT_BRANCH of NSPR.