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 at 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 at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===