what's wrong here? (ooplike)

[v3cz0r]

It worked when you added the extra-fields because an UDT assignament will call memcpy() and the 2 dummy fields allocated more space on stack, "moving" the function pointer fields down enough to not be overwritten.

"this" has to be changed to ptr or you will get an invalid data type, callocate() returns a pointer -- btw, "this" or "self" will probably be reserved later when classes are added.

As explained before, FB had to follow GCC 3.x ABI, that's quite complex, returning structs on registers when possible, it won't be simple to add, only prototypes are allowed atm, mainly to support the GSL library.

[fsw]

Now I know why it worked.
Thanks for the explanation.

So, to get it working properly I have to find a way to assign static memory and pass pointers back and forth to hold the data (and not loosing it) in the proper locations...

BTW the more you talk about the inner workings the more I'm impressed how much you have done already, and how little I know about...

Thanks again for all your hard work, it's truly appreciated.

[v3cz0r]

If you are assigning the UDT immediately after the function is called and if that function is not called inside threads, then it would be safe to use a static variable, for example

Code:

function func (...) as sometype ptr
static res as sometype
...
func = @res
end function

a = *func(a, b)

Adding proper debugging support now is being much harder than anything else, documentation is sparse, GDB has loads of unknown "features", boring trial-and-error attempts take too long.. ow, i can imagine how trying to follow GCC's 3.x OO ABI will be.. nm

[fsw]

But you know what?

I'm glad YOU do all the hard work :wink:

Thanks again.