Ok, I thought I'd ask I was doing some testing of my Carbon port today and
found a problem with
AsyncFilePlugin>>primitiveAsyncFileWriteStart:fPosition:fromBuffer:at:count:

It seems that it checks the buffer for type then wants to alter the buffer
count.

But I think it does it wrong, hence my question to the original authors...

(interpreterProxy isBytes: buffer)
    ifTrue: ["covert word counts to byte counts"
    count _ count * 4.
    ...

However as you noticed the comment doesn't match the logic, if the incoming
buffer is a byteArray it cheerfully sets count to count * 4, so if you write
10,000 bytes you really write 40,000 bytes.

The same applies for the read logic. Now the reason WHY the image doesn't
roll over and DIE when you attempt to read 40000 into that 10000 buffer is
interesting, it seems the readstart logic gets passed the unaltered size of
the buffer which dictates how much to actually read into a temporary buffer.
Both the actual read value 10,000 and the recalculated buffer size 40,000 is
examined and the lower value used when moving the data about.


So if someone wants to fixup their logic, and perhaps think about somewhere
else they might have made the same mistake when building all the plugin
logic, then let me know.

If anyone is using the AsyncFile logic, then your files are 4x bigger than
actually required.

--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
Custom Macintosh programming & various Smalltalk dialects
PGP Key: DSS/Diff/46FC3BE6
Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
===========================================================================