[squeak-dev] Re: Flaw in SocketStream>>peek detected

Andreas Raab andreas.raab at gmx.de
Thu Jan 14 07:06:23 UTC 2010


John M McIntosh wrote:
> Er, well also it's a timing issue just because you did the nextPutAll: and the flush. 

It's not a timing issue. Please run the code - it blows up after the 
response is received with an index out of bounds: 0 because it's trying 
to access lastRead and lastRead is zero at this point (nothing has been 
read thus far). No timing issues involved.

Cheers,
   - Andreas

> 
> (a) doesn't mean the GET/  actually got to the receiver, but it's in the network stack somewhere. 
> (b) stream peek will it return data, what if www.google.com never answers and closes the socket? 
> 
> 	"Receive data into the given buffer and return the number of bytes received. 
> 	Note the given buffer may be only partially filled by the received data.
> 	Waits for data once.  The answer may be zero (indicating that no data was 
> 	available before the socket closed)."
> 
> 
> 
> On 2010-01-13, at 10:29 PM, Andreas Raab wrote:
> 
>> Igor Stasenko wrote:
>>> The fix is:
>>> ---	^inBuffer at: lastRead
>>> +++	^inBuffer at: lastRead+1
>>> but i'm not sure if something else won't break because of it ;)
>> Extremely unlikely. It's pretty clear that peek is wrong here as illustrated by:
>>
>> stream := SocketStream openConnectionToHostNamed: 'www.google.com' port: 80.
>> stream nextPutAll:('GET / HTTP/1.0\\' copyReplaceAll: '\'with: String crlf).
>> stream flush.
>> stream peek.
>>
>> This blows up and clearly it shouldn't.
>>
>> Cheers,
>>  - Andreas
>>
> 
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
> 
> 
> 
> 
> 
> 




More information about the Squeak-dev mailing list