OpenSmalltalk
/
opensmalltalk-vm
20 mins and 56 secsEliot Miranda
CogVM source as per VMMaker.oscog-eem.2381
General:
** new primitive to compare strings (slang + JIT)
answers negative smi, 0 or positive smi (instead of 1, 2 or 3 in the MiscPlugin)
Spur:
Fix compiler bug with Apple LLVM version 7.0.0 (clang-700.1.76) for 64-bit Spur
segment loading where compiler bug eliminated second version check in segment
load when at -Os. Fix is to never inline the 32-bit word byte reversal.
Fix sign extension in printOop: et al on 64-bit Spur.
FFI Plugin:
Correct a 32bit-hardcoded pointer size in FFI
Correct two copy/paste typos in num32BitUnitsOf:
Nicolas Cellier:
Note: I don't like the FFI code that I just corrected. IMO, it does the wrong
thing.
if I have an argument spec is
MyLib>>foo: aFoo
<cdecl: void foo(Foo *)>
where Foo is some ExternalStructure subclass
(Foo class>>fields ^#((x 'ushort') (y 'ushort')))
and that I try to pass (MyLib new foo: Foo new), it seems to me that the
Foo new getHandle will be (ByteArray new: 4).
What I understand from the code that I just corrected is that we are trying to
pass the contents of the ByteArray re-interpreted as a void pointer.
Scary and wrong...
If I instead pass (MyLib new foo: Foo externalNew), it seems that we don't even
bother to check if the (argSpec anyMask: FFIFlagPointer) and just force passing
the structure by value (thru a memcpy on stack). Scary and wrong...
In general, every one use <cdecl: void foo(void *)> to work around this
ill-behavior, and thus bypass type checks...
Also note that we can't even pass an ExternalData (think an Array of Foo),
because ffiArgument:Spec:Class:in: insists on having
actualArg class inheritsFrom: argType referentClass.
ExternalData does not inherit from Foo, event if its type matches
(ExternalType structTypeNamed: #Foo). That's crazy...
Another reason while people use <cdecl: void foo(void *)>
It's high time to consider a rewrite IMO.
Git:
Add scripts to list modified and untracked files.
Want to know about upcoming build environment updates?
Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you!
SIGN UP HERE
Documentation about Travis CI
Have any questions? We're here to help. Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF: Konstantin Haase, Fritz Thielemann | Contact:contact@travis-ci.com | Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß §27 a Umsatzsteuergesetz: DE282002648
This email was sent to vm-dev@lists.squeakfoundation. org unsubscribe from this list