Closed callendorph closed 1 year ago
I'm really sorry. This is caused by the lack of a meaningful error message that repeatedly trips people up. It's been on our backlog for a while.
You have an external function called get_some_msg
that is declared in C, and hence needs to be called with the C calling convention.
public lostanza defn get-some-msg () -> ref<String> :
val msg:ptr<byte> = get_some_msg() ; <-- This line is incorrect.
return String(msg)
Here is the fix for it:
public lostanza defn get-some-msg () -> ref<String> :
val msg:ptr<byte> = call-c get_some_msg()
return String(msg)
This is a common mistake, and can easily waste a lot of time, so we're planning on adding an error message to catch this case.
Yup - that was it. I had used the call-c
construct for the elementary functions but I just brain farted on this one I guess.
This is a common mistake, and can easily waste a lot of time, so we're planning on adding an error message to catch this case.
Ya - that would be great.
Hi,
I'm trying to wrap the
gsl_strerror
function but I'm having a lot of trouble. This seems pretty straight forward so I'm wondering if I'm doing something wrong.Here is my stanza package for a small (hopefully) repeatable test case:
Here is a small C file with the function to import:
This is very similar to what the
gsl_strerror
function does.I can then build by adding this to my package file:
From the Stanza repo - I think String should create a new char buffer and copy the passed char pointer null-terminated string into it.
When I run this test - I get a
Seg Fault
For some reason - the
const char *
here always seg-faults. I've tried passing themsg:ptr<byte>
toclib/strlen
andclib/memcpy
. Both of those also segfault on themsg
object.I think the
const char *
here is going to be placed in a different memory section.So I then tried this C file:
So that I could find the
const char *
in memory. This program still seg faults.So it is definitely there.
So the address
0000000000820ca8
puts it some where at the end of the.data
section. The.data
section runs from 0x7a3140 to 0x820cb0. The length of the string is 21 bytes meaning the end of the const string is 0x820cbd. The next section.bss
starts at 0x820cc0. So I don't think there is an overlap issue. I'm not totally sure why it isn't into the string table but I'm guessing it is because of the way I've used the global variablesome_silly_msg
.Anyway - Thoughts ? Have you tried this before ? Is there something wrong with my setup ?