[usocket-devel] What's the usage of USOCKET::GET-HOST-NAME in lispworks.lisp?

Erik Huelsmann ehuels at gmail.com
Fri Feb 1 20:49:41 UTC 2008


On Feb 1, 2008 6:40 PM, Chun Tian (binghe) <binghe.lisp at gmail.com> wrote:
> Hi,
>
>
> On Feb 2, 2008, at 12:45 AM, Erik Huelsmann wrote:
>
> > On 2/1/08, Chun Tian (binghe) <binghe.lisp at gmail.com> wrote:
> >> Hi,
> >>
> >> I saw these definitions in lispworks.lisp:
> >>
> >>
> >> #+win32
> >> (fli:register-module "ws2_32")
> >>
> >> (fli:define-foreign-function (get-host-name-internal
> >> "gethostname" :source)
> >>      ((return-string (:reference-return (:ef-mb-string :limit 257)))
> >>       (namelen :int))
> >>      :lambda-list (&aux (namelen 256) return-string)
> >>      :result-type :int
> >>      #+win32 :module
> >>      #+win32 "ws2_32")
> >>
> >> (defun get-host-name ()
> >>  (multiple-value-bind (retcode name)
> >>      (get-host-name-internal)
> >>    (when (= 0 retcode)
> >>      name)))
> >>
> >> What's the usage of GET-HOST-NAME? Can we use CL:MACHINE-INSTANCE
> >> instead? I think they have the same effect.
> >
> > GET-HOST-NAME was added for cl-smtp, which depends on it. Is
> > "machine-instance" documented to return the hostname of the current
> > machine?
>
> I think it is. Yesterday I ask LispWorks Support about a FLI-function
> (system::gethostname) and got this answer from Martin Simmons:
>
>         You should certainly never call internal functions in the SYSTEM
> package!
>
>         Can you use CL:MACHINE-INSTANCE?  This returns the hostname on Mac/
> Linux and
>         what Microsoft call the "NETBIOS name" on Windows.

Ah. Ok, well, there's a difference with gethostname: it will try to
resolve to a fully qualified domain name (FQDN). When the FQDN
resolution fails (ie, the system isn't able to determine its own
"internet domain"), *then* it returns the "NETBIOS name". I think for
cl-smtp, the current implementation is best.

Anyway, now that the current implementation is there, there's no real
cost keeping it, is there? (In other words: why would we change
working code?)

I'll send my ideas about implementing datagram sockets in a next mail
this evening.


bye,


Erik.



More information about the usocket-devel mailing list