[Vm-dev] Re: [Pharo-dev] Question about errno and NB FFI

Eliot Miranda eliot.miranda at gmail.com
Tue Dec 15 21:52:15 UTC 2015


On Tue, Dec 15, 2015 at 1:34 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

> Hi guys,
>
> I am using NB FFI and I am calling a function that could answer a NULL* in
> case of error and that it should have set the number on *errno.*
>
> So now I have some questions:
>
> Say the code is this:
>
> run
> | whatever |
> whatever := self *primitiveWhatever*.
> ^ popenFile ifNil: [
> self *primitivePerror*.
>
> Imagine that the C lib called from #primitiveWhatever was the one setting
> *errno.*
> My question is... the following #primitivePerror is a DIFFERENT system
> call. Couldn't that happened that another error happened before the first
> system call and time I am executing the second one and so the "last error"
> (errno) is actually the wrong one I am thinking of?
>

Yes, which is why it's really important that the FFI be able to be told to
answer errno on error. See e.g. the VW FFI where IIRC one can specify that
if a call answers -1, the FFI call can fail with a primitive error code
that includes errno.


>
> Even worst, I may think that the scope of the  "global variable errno" may
> existed at the scope of the invoked lib only? In this case I don't have
> above problem, but then....how can I get such number once the NB primitive
> finished (so that I can call, for example,  strerror() ?
>

Well, there are two issues here.  One is that one should use waterer the
underlying platform defines for getting "errno", for example some platforms
will say something like #define errno get_errno(), to get the errno
specific to the current thread.  Second, all one's libraries need to use
the same approach so that errno is shared between the VM and the libraries,
otherwise your library may not set the errno seen by the VM and the FFI.



> Thanks in advance,
>
> --
> Mariano
> http://marianopeck.wordpress.com
>



-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151215/2d87e2cc/attachment.htm


More information about the Vm-dev mailing list