Revert 094d9124341e: not all libffi versions in use have a

ffi_prep_closure_loc() symbol.

1 files changed, 12 insertions, 8 deletions

diff --git a/c/_cffi_backend.c b/c/_cffi_backend.c
index 474ee06..32c8708 100644
--- a/c/_cffi_backend.c
+++ b/c/_cffi_backend.c
@@ -6284,17 +6284,21 @@ static PyObject *b_callback(PyObject *self, PyObject *args)
                      "return type or with '...'", ct->ct_name);
         goto error;
     }
-    /* NOTE: if we don't have CFFI_TRUST_LIBFFI, then this will invoke
-     * ffi_prep_closure_loc() with the last argument being equal to the
-     * first one.  With the current versions of libffi (June 2020), then
-     * this is just what occurs inside ffi anyway by calling
-     * ffi_prep_closure()---but this latter function is now deprecated.
-     * Please be aware that although this calls ffi_prep_closure_loc(),
-     * it is NOT always safe against read-write-execute memory attacks,
-     * as described in the lengthy comment before CFFI_TRUST_LIBFFI.
+    /* NOTE: ffi_prep_closure() is marked as deprecated.  We could just
+     * call ffi_prep_closure_loc() instead, which is what ffi_prep_closure()
+     * does.  However, cffi also runs on older systems with a libffi that
+     * doesn't have ffi_prep_closure_loc() at all---notably, the OS X
+     * machines on Azure are like that (June 2020).  I didn't find a way to
+     * version-check the included ffi.h.  So you will have to live with the
+     * deprecation warning for now.
      */
+#ifdef CFFI_TRUST_LIBFFI
     if (ffi_prep_closure_loc(closure, &cif_descr->cif,
                          invoke_callback, infotuple, closure_exec) != FFI_OK) {
+#else
+    if (ffi_prep_closure(closure, &cif_descr->cif,
+                         invoke_callback, infotuple) != FFI_OK) {
+#endif
         PyErr_SetString(PyExc_SystemError,
                         "libffi failed to build this callback");
         goto error;