[[ Bug 14057 ]] Implement Obj-C <-> LC arrays conversion for LCIDL (and ... - #1563

There might be an issue here with memory leaks. The reason we didn't implement the array API in 7.0 was because it was only used by lcidlc (support.mm) and it couldn't be implemented in a way that was leak-safe in 7.0 without a fair bit of overhead. The reason here is that the keys of an array, and elements were not copied - i.e. ownership of the key c-string would remain with the engine. However, with the move to 7.0, things are internally valuerefs, so any c-string which is returned must be freed by the caller. Also, pre-7.0, if an element of an array was an array, the caller did not have to release the reference to the element - I suspect this might be an issue also (it looks like you are creating MCExternalValues, but they are not released).

An alternative implementation strategy would be to implement the NS / CF conversions in the engine, bypassing the need to use the array API. The old code in support.mm could be kept, but just used when the engine version < 7.0 (i.e. an older external API version).

I believe we decided the policy on UTF8CString etc. was caller-free, so this should be fine - but I'm not sure the support.mm code has been updated (in the array conversion code) to take this into account.

We could fix the non-releasing of element values by adding a new option which indicates we want a copy (i.e. caller free) of the value. (kMCExternalValueOptionAsCopyOfVariable perhaps).

Its important the code in support.mm continue to work against 6.7 and 7.0 though - so it needs to switch on interface version and do the right thing in either case.

What is the status on this pull request? I have a project that is waiting on array support in lcidl externals and I would love to see this in the next 7.0 build.

Looking at this I think there is a problem with the engine-side NS value creation... Some are using NS methods, some are using CF methods.

We should be using CF functions for creation.

Then, NS and CF types should be exposed by the externals API (CF types can be new to V6).

When the engine returns an NS type it should use the internal CF constructor, then autorelease, then return.

Pending pull request adding the CF types: livecodesebastien#3

Reviewed-by: @runrevmark.

Hey guys, I've suddenly got build errors when using my externals in 6.7.2. Not sure where to start on this one. Looks like it's in libc++ so at a guess I might need to add it to all my .ios files but I'm a little confused as to why...

PS Commenting here instead of bugzilla or forums because I built against this branch.

@montegoulding, please create a Bugzilla ticket referencing this branch. Your issue is very likely to get lost if you don't.

@montegoulding: We've finally got to the bottom of this problem - it is because of the implicit default c++ library being used. This differs depending on min-os-version.

Pull request #1881 should fix the problem - we've moved to using libc++ as that means externals can use C++11 if they wish... However, if you are relying on any third-party static libraries you do not compile for your externals and they are still using libstdc++ (which is the old GNU one) then we might have to rethink this. (Ideally though, they would have libc++ linked versions too).

Thanks @runrevmark does this mean the liposuction on the other pull request is out the window? So I guess we just need the same change as in #1881 to lclink.sh?

@montegoulding: Can you clarify what you mean by "does this mean the liposuction on the other pull request is out the window"?

In regards to lclink.sh - I knew there was a file I had failed to update! We'll sort that out...

Sorry @runrevmark that was a bit cryptic I guess. I meant @runrevsebastien's #1868 where things are built for each architecture and then lipo'd together.

@montegoulding: That was one of the things we tried before realizing it was to do with default C++ library... I think (given the min-os-version we compile with) has to be different for the ARM64 vs ARMv7 slice that keeping the lipo-action in is probably a good idea... Just in case there are any other implicit settings which that changes. I'll chat to @runrevsebastien about it today though.

@montegoulding: We decided to leave the lipo-action in as we have to specify different min versions on the slices. @runrevsebastien finished getting the simulators working and updated lc-link.sh today: #1889