libsodium on LiveCode?

[Monte Goulding]

> On 20 Feb 2018, at 4:44 pm, Brian Milby via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> I was finally able to get the init to return a 0 or 1 (success or already
> initialized).   I switched to `code\x86-win` - not sure if that had any
> effect based on the other major change I made…

I think it will find both win and win32 in the IDE at the moment. I have just submitted patches. It’s bug 20991.

> Turns out I was using the wrong version of the dll.  If anyone else wants
> to try, here's the path that actually worked:
> \libsodium-1.0.16-msvc.zip\Win32\Release\v100\dynamic\libsodium.dll (2
> other files there that I included as well)
> I was initially trying a different archive, but then switched to the msvc
> version.  I started with v141 which didn't work.  I went ahead and tried
> v100 which did.  There are also v110, v120, and v140.  I don't know what
> the differences are, but at this point am just happy that I can get the
> library initialized.  I'll eventually try others and try to figure out what
> the numbers mean.

These are VS toolchain versions. v140 is 2015 and v141 is 2017. I’m not sure if dynamic in that path refers to it being a dll v lib or the CRT linking. If there’s a folder with static/libsodium.dll then use that. It may be that resolves your issue with v141...
> 
> @Monte, I was using __safe based on a thread that Mark W commented in on
> the forum.  Essentially if the library is returning just an integer then it
> would probably be safe.
> http://forums.livecode.com/viewtopic.php?f=93&t=30429 <http://forums.livecode.com/viewtopic.php?f=93&t=30429>

Ah, well, I’m not as smart as Mark so I just let everything that’s not in the engine default to unsafe ;-)
> 
> Thanks on the hints on sending data to the library.  I'm also going to need
> to receive keys back from the library.  I'm guessing that where it is
> listed as pK[32] that it will overwrite the data in the passed in string.
> There are other calls that use a pointer and a length as separate arguments
> to the function, so the calls provided will be useful there (those are for
> encrypting/decrypting content).  I'll probably need to dive into the source
> to understand that a bit more (unless their api docs cover it).

So you need a buffer as inout for the library to write to? Something like this.

__safe foreign handler MCDataCreateWithBytesAndRelease(in pBytes as Pointer, in pCount as LCUIndex, out rData as Data) returns CBool binds to "<builtin>"
__safe foreign handler MCMemoryAllocate(in pSize as LCUIndex, out rBlock as Pointer) returns CBool binds to "<builtin>”
__safe foreign handler MCMemoryDeallocate(in pBlock as Pointer) returns nothing binds to "<builtin>”

variable tBuffer as Pointer
if not MCMemoryAllocate(32, tBuffer) then
   throw “uh oh”
end if

CallThingThatSetsBuffer(tBuffer)

variable tData as Data
if not MCDataCreateWithBytesAndRelease(tBuffer, 23, tData) then
   MCMemoryDeallocate(tBuffer)
   throw “uh oh"
end if

return tData

> 
> Now that I can actually talk to the code, I should be able to experiment.
> 
> 
> Here's something that I got working to return the version:
> 
> private __safe foreign handler _sodium_library_version_major() returns CInt
> binds to "c:libsodium>sodium_library_version_major"
> private __safe foreign handler _sodium_library_version_minor() returns CInt
> binds to "c:libsodium>sodium_library_version_minor"
> public handler sodiumVersion() returns String
> variable tResult as String
> put "Version " into tResult
> put _sodium_library_version_major() formatted as string after tResult
> put "." after tResult
> put _sodium_library_version_minor() formatted as string after tResult
> return tResult --"Version 10.1"
> end handler
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode