[Sbcl-devel] Windows buglets

[Christophe R. <cs...@ca...>]

Hi,

Since I'd cunningly managed to forget my access card this morning, I
spent an hour (waiting for other people to show up) in the open access
labs, where I got to play with windows machines.  I spent my time

* building SBCL.  As well as the expected sb-simple-streams failure,
  sb-md5 failed for me, apparently because there is no "nul"
  file-or-file-like-thing.  I'm using MSYS (whatever was current about
  a week ago) and other bits of MinGW.

* installing SLIME.  I've now committed my small patch to use the NIL
  communication-style when :win32 is present in *FEATURES*, to be
  reverted when SBCL gains enough functionality to have either working
  serve-event or working threads.  With that patch, it is mostly hunky
  dory except that each startup of slime causes about 1000 lines of
  compiler output.  It turns out that this isn't as I first thought a
  question of file-write-date being wrong; instead, it's because the
  win32 implementation of various accessors is a lot lower level, and
  also because there are some questionable implementation issues.  For
  instance, gethostbyaddr() and gethostbyname() are declared to return
  (struct hostent)s, but surely they in fact return (* struct
  hostent)?  Also, the use of macros (rather than functions) for
  e.g. hostent-addresses is going to cause compilation notes for more
  code; I think under the systems where sb-grovel is used, the
  definition ends up being something like
    (defun hostent-addresses (ent)
      (declare (optimize speed) (type (alien (* (struct hostent))) ent))
      (slot ent 'h_addr_list))
  or something, which I believe doesn't cause the compiler to throw a
  wibbly.

This is a relatively minor thing, but it would be nice if it could be
fixed before we release 0.9.12 so that we have a release version with
a tolerable user experience... is there anyone out there with
resources to spend on this?

Cheers,

Christophe