Thanks for chasing this one down. WinSock only supports 'short's as protocol numbers in 'protoent's, whereas 'int's seems to be the norm, hence the garbled result.
Shouldn't be too hard to fix. --sigbjorn ----- Original Message ----- From: "Claus Reinke" <[EMAIL PROTECTED]> To: "Simon Peyton-Jones" <[EMAIL PROTECTED]>; "Sigbjorn Finne" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, March 07, 2003 11:06 Subject: getProtocolNumber garbage (was: Network on Win98: failed - socket - no error ??) > > okay, after giving myself a day to recover from the frustration, > I've given it fresh try today, and can at last report the source > of the problem and a workaround (thanks to Sigbjorn for helping > me to narrow down the source). I leave precise location of the > bug and proper fix to the experts:-) > > ghc's 'getProtocolNumber "tcp"' returns garbage on my win98 box > (ghc-5.04.2, perhaps a marshalling problem??). > > perl's version gives me: 6 > ghc's version gives me: 1398538246 > > Putting in the more sensible value explicitly makes the program > work as expected, so winsock was really quite right to report > > WSAEAFNOSUPPORT 10047 > Address family not supported by protocol family, > > just that I didn't expect the error to be with the parameters.. > (and my hacked-up error-reporting didn't include the > erroneous values themselves..). > > > On the topic of libraries: although ghc doesn't value binary compatibility > as high as its user's do;-) I would expect the libraries to develop faster than > ghc's binary incompatibilities in the near future (or is this unreasonable?). > > So it would really be useful to have regular binary snapshots of the libaries, > built to work with(*) the latest binary release of GHC, but distributed separately. > When the current libraries can no longer be built for the latest GHC release, it's > a sure sign that a new one is needed.. > > (*) note that this might well be different from "built with", as long as the ghc > modifications needed do not compromise binary compatibility. > > >A word of caution here. Parts of the libraries, especially base/GHC/*, > >may be GHC-version-specific. We do not put lots of ifdefs in the > >library sources to cope with different GHC versions, because they are > >expected to be built with the GHC from the same tree. > >So, it may work, but it may not. > > The usual cvs-rule is not to check in things that don't compile, so even > without lots of ifdefs, it would be useful to have a simple text file for > each package, stating the version of GHC/Hugc/nhc with which it was > compiled (and wether or not it compiles with the latest binary release?). > > Btw, does the web interface to the cvs-tree give me an easy way to see > the precise source versions wich make up the latest binary release? I find > it difficult to check whether there have been any changes relevant to my > problems. A good start would be to have the tag for the latest binary release > as the selected diff target by default? > > Finally cheerful again, > Claus > > > _______________________________________________ > Glasgow-haskell-bugs mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs _______________________________________________ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
