Win Tims Money! a.k.a. find my sockets bug!

Duane Maxwell dmaxwell at entrypoint.com
Fri Apr 21 21:14:04 UTC 2000


Tim -

So how is this going to work?

Are you paying John and then I'm paying you?

Note to lurkers - this is a _really_ interesting bug, and it's a wonder it
hasn't popped up before.  It seems to happen due to addition of sign
extended numbers.  This big clue in John's IP example is that the high byte
ended getting  reduced by one - or alternatively had 16rFF added to it -
which is what happens if the byte below gets sign extended...

How does this happen?  Well, it appears than with some compilers,
ObjectMemory>>fetchByte:ofObject: will return a sign-extended char.  I
would hypothesize that this is not the intended behavior.

So, I think the actual fix is:

ObjectMemory>>fetchByte: byteIndex ofObject: oop

 ^ self byteAt: (self cCoerce: oop to: 'unsigned char *') + BaseHeaderSize
+ byteIndex


>In message <200004212016.PAA09260 at dcs-server1.cs.uiuc.edu> you wrote:
>
>> Ok, found it I'll only claim a $1.00 since I've not posted the solution
>> however in the code given this problem:
>>
>> D0DA0301 is the byte array for www.disney.com  (208.218.3.1)
>>
>> when you invoke
>> addr = netAddressToInt(address);
>>
>> then addr gets
>> CFDA0301  which of course is 207.218.3.1
>>
>> The problem lurks in netAddressToInt when it grabs bytes and shifts then
>> adds them I think some compilers think and do signed math?
>
>Yup, that's it. Hacking the generated C to use unsigned char* instead of
>char * makes it work. I'll clean up the slang later after a drunken orgy
>of celebration. Thank you John, you get the prize, the adulation, the
>girls/boys/goats (delete as appropriate).
>
>Oh, the joy of C. :-(
>
>tim
>--
>Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
>To be, or not to be, those are the parameters.







More information about the Squeak-dev mailing list