Different environments in NIF API calls

Sverker Eriksson sverker.eriksson@REDACTED
Tue Feb 23 18:56:21 CET 2021

The ‘env’ argument of functions that only read supplied terms (like enif_get_* functions) is not used in current implementation. And as we have introduced functions like enif_compare that lacks ‘env’ arguments, it is now impossible to do an implementation of the API where ERL_NIF_TERM’s are not self contained.


So, yes you can use enif_get_map_value with map and key argument from different environment. The same goes for enif_compare and all other functions with term arguments that are only read and not referred by new constructed terms.





From: erlang-questions <erlang-questions-bounces@REDACTED> On Behalf Of Harris, Robert
Sent: den 23 februari 2021 13:21
To: erlang-questions@REDACTED Questions <erlang-questions@REDACTED>
Subject: Different environments in NIF API calls



I'm trying to understand the full implications of

"All API functions that read or write terms has the environment
that the term belongs to as the first function argument."

For example, can enif_get_map_value() be called with a map from
a process-bound environment and a key from a process-independent
one? If so, which environment would be used?

Similarly, does enif_compare require that its arguments share
the same environment?



Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.


The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210223/cc234ba2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5509 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20210223/cc234ba2/attachment.bin>

More information about the erlang-questions mailing list