[squeak-dev] An issue with Collections-ul.667

Chris cunningham.cb at gmail.com
Thu Feb 18 17:28:17 UTC 2016


That sounds like a decent compromise.  I would strongly request that a ByteArray>>signedByteAt:(put:) exist in the base image. The lack was why it was added - and it is useful for add-on packages such as my Kafka one. 

Thanks,
CNBC

Sent from my iPhone

> On Feb 16, 2016, at 1:41 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> Hi Levente,
> 
>     I just wanted to note a potential problem with Collections-ul.667
> 
> Name: Collections-ul.667
> Author: ul
> Time: 10 October 2015, 3:40:46.732 pm
> UUID: 7cd785ff-1839-4075-ac56-4b71054529d8
> Ancestors: Collections-topa.666
> 
> Added the missing methods of ByteArray's platform independent access category: #signedByteAt: #signedByteAt:put: #long64At:put:bigEndian: and #long64At:bigEndian:. The 64-bit methods are not optimized.
> 
> 
> In this version you provided ByteArray>>#signedByteAt:[put:] which conflicts with FFI-Kernel's methods of the same name.  There's a difference in semantics.  If you look at ExternalStructure's class comment it points out that
> 
> "This class provides an abstract base for all structures that can be used by external functions. ExternalStructures have two possible handle types:
> 	- ExternalAddress
> 		If the handle is an external address then the object described does not reside in the Smalltalk object memory.
> 	- ByteArray
> 		If the handle is a byte array then the object described resides in Smalltalk memory.
> Useful methods should be implemented by subclasses of ExternalStructure using the common ByteArray/ExternalAddress platform dependent access protocol which will transparently access the correct memory location."
> 
> i.e. the primitives used automatically differentiate between an ExternalAddress holding a pointer to external memory, in which case the datum is accessed via that location, or a ByteArray, in which case the datum is accessed in the ByteArray.  Your versions only do the latter and would hence misinterpret data in ExternalAdderss instances.  Here's the FFI code:
> 
> ByteArray>>signedByteAt: byteOffset
> 	"Return a 8bit signed integer starting at the given byte offset"
> 	^self integerAt: byteOffset size: 1 signed: true
> 
> ByteArray>>integerAt: byteOffset size: nBytes signed: aBoolean
> 	"Primitive. Return an integer of nBytes size from the receiver.
> 	Note: This primitive will access memory in the outer space if
> 	invoked from ExternalAddress."
> 	<primitive: 'primitiveFFIIntegerAt' module:'SqueakFFIPrims'>
> 	^self primitiveFailed
> 
> And here's yours:
> ByteArray>>signedByteAt: index
> 	"Return an 8-bit signed integer quantity from the given byte index."
> 	
> 	| byte |
> 	(byte := self at: index) <= 16r7F ifTrue: [ ^byte ].
> 	^byte - 16r100
> 
> Now of course this isn't an issue in builds that load the FFI after Collections, but it does affect images in which FFI-Kernel was loaded and then the image was updated to instal Collections-ul.667.
> 
> I'm not sure what the right fix is, but I thought I'd better mention it.  One obvious one is to implement the FFI methods in ExternalAddress>>#signedByteAt:[put:], and if folks agree I can do this.  Let me know.  Pharoers, if I do this, you'll need to make sure that the Pharo base includes ByteArray>>#signedByteAt:[put:].
> 
> _,,,^..^,,,_
> best, Eliot
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160218/df854bc3/attachment.htm


More information about the Squeak-dev mailing list