bug in host-to-vector-quad on lispworks (also host-to-vector-quad)

[Mark H. David]

Running usocket-0.7.0.1 in LispWorks 7.1.0. In my system it happens currently that

(get-hosts-by-name "localhost") 

returns the following list:

(#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) #(127 0 0 1))

Then get-host-by-name simply takes the first of that list and returns it.

Host-to-hbo expects the result of get-host-by-name to always be a vector quad, so the result of calling it with "localhost" is an error on the recursive call with the result of (get-host-by-name "localhost") => #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1)

The error message is due to falling out of the ecase:

  #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) fell through ETYPECASE expression inside USOCKET::HOST-TO-HBO.

I observed that host-to-vector-quad gives the wrong result, a 16-byte instead of a 4-byte vector, due to the same root cause, but it will happen "randomly". The reason is it uses get-random-host-by-name, which chooses a random element of the same result list returned by (get-hosts-by-name "localhost").  For example, I just ran this in the REPL -- log:

  USOCKET> (loop repeat 10 for r = (host-to-vector-quad "localhost") when (not (= (length r) 4)) collect r)
  (#(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1) #(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1))

This seems to be LispWorks only. I tried this on SBCL and CCL, but I could not recreate similar problems. Also, not all MacOS installs seem to get this weird ipv6 localhost the way I do. I'm not sure why I'm getting this. I do not remember doing anything special or any kind of stuff with ipv6, but apparently something I've done has "infected" me with it.  However, I can say I do not notice other networking issues on my system.

Thanks,
Mark