github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM/MVM_malloc_etc: 54a5091119 | (Nicholas Clark)++ | 4 files
Use MVM_{malloc,realloc,calloc,free} consistency.

All these calls changed to the MVM_* wrappers are on memory blocks where the other calls are MVM_* wrappers.
There are still a few "bare" `malloc`s/`free`s, but these seem to be self-contained, or related to memory allocated by `strdup`/`strndup`, which is using the platform `malloc` internally.		 09:40
MoarVM: 88722e8ecc | (Ben Davies)++ | src/core/alloc.h
Fix zeroing of reallocated memory in MVM_recalloc

This function assumes that the new size of memory to be reallocated is greater than or equal to its old size. Should it be lesser instead, this will attempt to zero memory that is out of bounds, leading to a segfault. Only attempt to zero reallocated memory if its size has grown.		 09:44
MoarVM: 5c791a4810 | nwc10++ (committed using GitHub Web editor) | src/core/alloc.h
Merge pull request #1366 from Kaiepi/mvm-recalloc-zeroing

Fix zeroing of reallocated memory in MVM_recalloc
nwc10 if I got the instructions correct, "dangerous but awesome" waits until Monday. Whereas that one is more "awesome was dangerous" 09:46
Geth MoarVM: nwc10++ created pull request #1368:
Use MVM_{malloc,realloc,calloc,free} consistency.
Altai-man Release packages are built, so it's probably safe to release the PRs. 09:54
nwc10 Oh Belgium! (Clearly I need peril sensitive sunglasses) 11:12
either I am massively misunderstanding some nuance of the specs 11:13
or *they lie*
Oracle's own compiler on Solaris is generting assembly consistent with gcc on sparc linux
but not Oracle's documented spec
and, hah! libffi works fine on sparc64 linux for the test in question 11:14
the SIGBUG is "Anything you still can’t cope with is therefore your own problem" 11:16
OK, this is looking like a subtle bug in nativecall 11:47
I see that there exists
void dcArgShort (DCCallVM* vm, DCshort value);
but no corresponding dcArgUshort 11:48
and on sparc64 the ABI behaviour is different for unsigned and signed shorts
(and chars)
(and ints don't behave like the documented spec)
and you only notice this if your code is sufficiently "simple" (or unlucky) enough to care about the exact bit representation that comes in, in the register used as part of the ABI 11:49

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!