diff options
| author | Armin Rigo <arigo@tunes.org> | 2020-07-17 10:38:07 +0200 |
|---|---|---|
| committer | Armin Rigo <arigo@tunes.org> | 2020-07-17 10:38:07 +0200 |
| commit | c421c605a3fd6dd2d96f5969d4ca368b4fd12b20 (patch) | |
| tree | 0f596bb6e357813137dcbdb68ca5e56e67f3bcaa /c | |
| parent | d4305759c2355db4c450d58ca2c236d879fa4790 (diff) | |
| download | cffi-c421c605a3fd6dd2d96f5969d4ca368b4fd12b20.tar.gz | |
Comment more
Diffstat (limited to 'c')
| -rw-r--r-- | c/_cffi_backend.c | 5 |
1 files changed, 4 insertions, 1 deletions
diff --git a/c/_cffi_backend.c b/c/_cffi_backend.c index 8e76880..e6adf3c 100644 --- a/c/_cffi_backend.c +++ b/c/_cffi_backend.c @@ -6290,7 +6290,10 @@ static PyObject *b_callback(PyObject *self, PyObject *args) * 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. + * deprecation warning for now. (We could try to check for an unrelated + * macro like FFI_API which happens to be defined in libffi 3.3 and not + * before, but that sounds very obscure. And I prefer a compile-time + * warning rather than a cross-version binary compatibility problem.) */ #ifdef CFFI_TRUST_LIBFFI if (ffi_prep_closure_loc(closure, &cif_descr->cif, |