On 7 Oct 2017, at 00:11, Hern��n Morales Durand <hernan.morales@gmail.com> wrote:

2017-10-06 2:39 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:

On 6 Oct 2017, at 05:34, Hern��n Morales Durand <hernan.morales@gmail.com> wrote:

Hi Nicolas

2017-10-05 16:04 GMT-03:00 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:

2017-10-05 15:42 GMT+02:00 Hern��n Morales Durand <hernan.morales@gmail.com>:

I tried, now I get an exception "Use ExternalAddress instead!"

I guess the message means Use ExternalAddres in the "out" parameter.
But replacing byte with ExternalAddress also crashes the VM (crash.dmp
attached).

2017-10-05 10:03 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:

On 5 Oct 2017, at 14:55, Hern��n Morales Durand
<hernan.morales@gmail.com> wrote:

Forgot to comment that Nacl worked in Pharo 5.

yes but that was with NB and there are some minimum differences.
I do not have the library and I lack the time to try more, but seems to
me that here:

apiCryptoHashSha512Output: outByteArray input: inByteArray inputLength:
inByteArrayLength

      ^ self
              ffiCall: #(long crypto_hash_sha512_ref (byte *
outByteArray, byte * inByteArray, ulonglong * inByteArrayLength))
              module: 'libsodium��.

instead "byte * outByteArray��, you want "byte **outByteArray��

can you try?

Esteban

Hmm no, internet reference says:

extern int crypto_hash_sha512_ref(unsigned char *,const unsigned char
*,unsigned long long);

The error is rather that you pass the address of length rather than the
length...
So you pass an erroneous length that may lead to a segfault...

Yes, that extra * was the error indeed.
Thank you Nicolas.

I do not know the VM internals, however I wonder if it is
understandable to expect a VM crash for a typo like this?
Maybe it is too difficult to catch in the VM side?

Just asking, not criticizing anyone's work.

Of course that is normal. This is C code, any error has the potential to crash your program. In C there are no runtime safe guards.

There is a reason why we like/use Pharo.

However there are a couple of lightweight libraries which claim to
provide exceptions for C:
https://github.com/guillermocalvo/exceptions4c or this one
https://github.com/psevon/exceptions-and-raii-in-c

I wonder if something like that could be used in UFFI

Nothing in C *ever* will save you from accessing bad memory blocks. And yes, it will always crash your program.

those links you point are exception mechanisms, a set of tools to easy the catch of programming exceptions.

But, if you try to read a chunk of memory in, say 0x8000 and the data/function that should be there is now garbage, you��re screw.

as Sven pointed, that��s why we use higher level languages, with GC and all that.

Esteban

Hern��n

Cheers,

Hern��n

2017-10-05 3:23 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
H Hernani,

Most probably is a problem in the library and not UFFI, but I could
not know without a crash report.

Esteban

On 5 Oct 2017, at 06:00, Hern��n Morales Durand
<hernan.morales@gmail.com> wrote:

Hi,

I ported Nacl (a libsodium wrapper) from the old FFI apicall: format
to use the UFFI ffiCall:, but there should be something terribly
wrong
because is crashing the VM, in both Windows 8.1 and Linux.

How to reproduce in Pharo 6.1

Metacello new
smalltalkhubUser: 'tonyg' project: 'Crypto-Nacl';
configuration: 'Nacl';
version: #development;
load.

(Nacl hashString: 'The quick brown fox jumps over the lazy dog') hex

This one does deserve a bug entry?

Cheers,

Hern��n