Log message:
py-cffi: updated to 1.11.3

v1.11.3
Fix on CPython 3.x: reading the attributes __loader__ or __spec__ from the \ 
cffi-generated lib modules gave a buggy SystemError. (These attributes are \ 
always None, and provided only to help compatibility with tools that expect them \ 
in all modules.)
More Windows fixes: workaround for MSVC not supporting large literal strings in \ 
C code (from ffi.embedding_init_code(large_string)); and an issue with \ 
Py_LIMITED_API linking with python35.dll/python36.dll instead of python3.dll.
Small documentation improvements.

Log message:
py-cffi: update to 1.11.2

v1.11.2
Fix Windows issue with managing the thread-state on CPython 3.0 to 3.5

Log message:
py-cffi: update to 1.11.1

v1.11.1
Fix tests, remove deprecated C API usage
Fix (hack) for 3.6.0/3.6.1/3.6.2 giving incompatible binary extensions
Fix for 3.7.0a1+

Log message:
py-cffi: update to 1.11.0

v1.11
Support the modern standard types char16_t and char32_t. These work like \ 
wchar_t: they represent one unicode character, or when used as charN_t * or \ 
charN_t[] they represent a unicode string. The difference with wchar_t is that \ 
they have a known, fixed size. They should work at all places that used to work \ 
with wchar_t (please report an issue if I missed something). Note that with \ 
set_source(), you need to make sure that these types are actually defined by the \ 
C source you provide (if used in cdef()).

Support the C99 types float _Complex and double _Complex. Note that libffi \ 
doesn’t support them, which means that in the ABI mode you still cannot call C \ 
functions that take complex numbers directly as arguments or return type.

Fixed a rare race condition when creating multiple FFI instances from multiple \ 
threads. (Note that you aren’t meant to create many FFI instances: in inline \ 
mode, you should write ffi = cffi.FFI() at module level just after import cffi; \ 
and in out-of-line mode you don’t instantiate FFI explicitly at all.)

Windows: using callbacks can be messy because the CFFI internal error messages \ 
show up to stderr—but stderr goes nowhere in many applications. This makes it \ 
particularly hard to get started with the embedding mode. (Once you get started, \ 
you can at least use @ffi.def_extern(onerror=...) and send the error logs where \ 
it makes sense for your application, or record them in log files, and so on.) So \ 
what is new in CFFI is that now, on Windows CFFI will try to open a non-modal \ 
MessageBox (in addition to sending raw messages to stderr). The MessageBox is \ 
only visible if the process stays alive: typically, console applications that \ 
crash close immediately, but that is also the situation where stderr should be \ 
visible anyway.

Progress on support for callbacks in NetBSD.

Functions returning booleans would in some case still return 0 or 1 instead of \ 
False or True. Fixed.

ffi.gc() now takes an optional third parameter, which gives an estimate of the \ 
size (in bytes) of the object. So far, this is only used by PyPy, to make the \ 
next GC occur more quickly (issue 320). In the future, this might have an effect \ 
on CPython too (provided the CPython issue 31105 is addressed).

Add a note to the documentation: the ABI mode gives function objects that are \ 
slower to call than the API mode does. For some reason it is often thought to be \ 
faster. It is not!

Log message:
Use libffi's closure handling based on code from the upstream branch.
Adjust test cases to not use alloca.h on NetBSD. Use a temporary
directory under WRKDIR and allow C++ when test builds are requested.

Log message:
Do not run tests that segfault on NetBSD. Add upstream bug report URL.

Log message:
Updated py-cffi to 1.10.0.

v1.10

    Issue #295: use calloc() directly instead of PyObject_Malloc()+memset()
    to handle ffi.new() with a default allocator. Speeds up
    ffi.new(large-array) where most of the time you never touch
    most of the array.
    Some OS/X build fixes (“only with Xcode but without CLT”).
    Improve a couple of error messages: when getting mismatched
    versions of cffi and its backend; and when calling functions
    which cannot be called with libffi because an argument is a
    struct that is “too complicated” (and not a struct pointer,
    which always works).
    Add support for some unusual compilers (non-msvc, non-gcc,
    non-icc, non-clang)
    Implemented the remaining cases for ffi.from_buffer. Now all
    buffer/memoryview objects can be passed. The one remaining check
    is against passing unicode strings in Python 2. (They support
    the buffer interface, but that gives the raw bytes behind the
    UTF16/UCS4 storage, which is most of the times not what you
    expect. In Python 3 this has been fixed and the unicode strings
    don’t support the memoryview interface any more.)
    The C type _Bool or bool now converts to a Python boolean when
    reading, instead of the content of the byte as an integer. The
    potential incompatibility here is what occurs if the byte
    contains a value different from 0 and 1. Previously, it would
    just return it; with this change, CFFI raises an exception in
    this case. But this case means “undefined behavior” in C; if
    you really have to interface with a library relying on this,
    don’t use bool in the CFFI side. Also, it is still valid to use
    a byte string as initializer for a bool[], but now it must only
    contain \x00 or \x01. As an aside, ffi.string() no longer works
    on bool[] (but it never made much sense, as this function stops
    at the first zero).
    ffi.buffer is now the name of cffi’s buffer type, and ffi.buffer()
    works like before but is the constructor of that type.
    ffi.addressof(lib, "name") now works also in in-line mode, not
    only in out-of-line mode. This is useful for taking the address
    of global variables.
    Issue #255: cdata objects of a primitive type (integers, floats,
    char) are now compared and ordered by value. For example, <cdata
    'int' 42> compares equal to 42 and <cdata 'char' b'A'> compares
    equal to b'A'. Unlike C, <cdata 'int' -1> does not compare equal
    to ffi.cast("unsigned int", -1): it compares smaller, because
    -1 < 4294967295.
    PyPy: ffi.new() and ffi.new_allocator()() did not record “memory
    pressure”, causing the GC to run too infrequently if you call
    ffi.new() very often and/or with large arrays. Fixed in PyPy
    5.7.
    Support in ffi.cdef() for numeric expressions with + or -.
    Assumes that there is no overflow; it should be fixed first
    before we add more general support for arbitrary arithmetic on
    constants.

Log message:
Run self-tests using py.test, better readable output.

Remove mprotect comment; even with it turned off, a segfault happens.

Log message:
Updated py-cffi to 1.9.1.

v1.9

    Structs with variable-sized arrays as their last field: now we
    track the length of the array after ffi.new() is called, just
    like we always tracked the length of ffi.new("int[]", 42). This
    lets us detect out-of-range accesses to array items. This also
    lets us display a better repr(), and have the total size returned
    by ffi.sizeof() and ffi.buffer(). Previously both functions
    would return a result based on the size of the declared structure
    type, with an assumed empty array. (Thanks andrew for starting
    this refactoring.)
    Add support in cdef()/set_source() for unspecified-length arrays
    in typedefs: typedef int foo_t[...];. It was already supported
    for global variables or structure fields.
    I turned in v1.8 a warning from cffi/model.py into an error:
    'enum xxx' has no values explicitly defined: refusing to guess
    which integer type it is meant to be (unsigned/signed, int/long).
    Now Iâm turning it back to a warning again; it seems that
    guessing that the enum has size int is a 99%-safe bet. (But
    not 100%, so it stays as a warning.)
    Fix leaks in the code handling FILE * arguments. In CPython 3
    there is a remaining issue that is hard to fix: if you pass a
    Python file object to a FILE * argument, then os.dup() is used
    and the new file descriptor is only closed when the GC reclaims
    the Python file objectâand not at the earlier time when you
    call close(), which only closes the original file descriptor.
    If this is an issue, you should avoid this automatic convertion
    of Python file objects: instead, explicitly manipulate file
    descriptors and call fdopen() from C (...via cffi).

Log message:
Add patch to distinfo and bump PKGREVISION for it.

('make test' still fails with mprotect enabled.)