Let me turn that around and suggest code in Smalltalk versus in C primitives, then anyone can participate. Not that one can't suggest VM changes, it's just way easier for all parties if it's in the image...
englishErrorForSocketPrims: anErrorCode ^EnglishErrorCodes for: anErrorCode hint: #SocketPrims
where hint tells me something about the primitive being used, thus I've a handle on the fact it's from the SocketPrims
The just do something like platform _ Smalltalk platformName. platform = 'Mac OS' ifTrue: [Smalltalk osVersion asInteger >= 1000 ifTrue: [stuff for osx ] ifFalse: [stuff for os 9 and earlier]]. "Note that actually for os-x you would need to consider VM version to demarcate OpenTransport versus BSD sockets plus another check for Classic under os-x and I'm not quite sure how to get a handle on which operating system type & version you have..."
The stuff for the operating system then would resolve that 61 means #ECONNREFUSED, versus 111 or 146...
I would suspect there is a reasonably small set of errors code between all unix flavors and also have reasonable meaning in os-9 and windows. Additional error codes could be added per operating system/version as the coder see fit.
On Aug 25, 2004, at 10:46 AM, John Pfersich wrote:
I'd like to make a suggestion to the VM maintainers. It would be nice to get the actual error message back from the OS, but one that would be platform independent, so that a developer could, if they choose, try to recover from the error.
For example, the C macro ECONNREFUSED is mapped to 61 on OSX, 111 on Linux, and 146 on Solaris; and ETIMEDOUT is mapped to 60 on OSX, 110 on Linux, and 145 on Solaris. (sorry, no Windows examples, I've not coded in Windows since the early 90's.)
I think it would be nice to have a new primitive that returns a platform independent code instead of the raw error code. Then we could add a new method that gives the developer access to that value.
As an aside to Kamil Kukura, you might want to use the message statusString for now, I think it might work better than socketError does for now.
I'll be the first to say this is all a bit ill defined. You really need to check the C source code for the socket support code to understand what is happening. For os-x on or after the carbon VM 3.5.1b2 we switched to the Unix BSD socket code. The socketError primitive returns the results of capturing errno, or getsockopt(s, SOL_SOCKET, SO_ERROR, (void *)&error, &errsz) depending on what is happening at the time. This all assumes us VM folks capture the error data and don't have multiple calls trashing things (accept processing comes to mind).
Really one needs to review the C source code for the called primitive at the time of the error is required to understand where the data comes from.
On the other hand, sticking some documentation in the Socket>>socketError could be useful.
--
== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ====================================================================== == ===
-- ---------------------------------------------------- Source code in files. How quaint. -- Kent Beck
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===