[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
|