EVOLUTION-MANAGER
Edit File: whatsnew.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>What’s New — CFFI 1.9.1 documentation</title> <link rel="stylesheet" href="_static/default.css" type="text/css" /> <link rel="stylesheet" href="_static/pygments.css" type="text/css" /> <script type="text/javascript"> var DOCUMENTATION_OPTIONS = { URL_ROOT: '', VERSION: '1.9.1', COLLAPSE_INDEX: false, FILE_SUFFIX: '.html', HAS_SOURCE: true }; </script> <script type="text/javascript" src="_static/jquery.js"></script> <script type="text/javascript" src="_static/underscore.js"></script> <script type="text/javascript" src="_static/doctools.js"></script> <link rel="top" title="CFFI 1.9.1 documentation" href="index.html" /> <link rel="next" title="Installation and Status" href="installation.html" /> <link rel="prev" title="CFFI documentation" href="index.html" /> </head> <body> <div class="related"> <h3>Navigation</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="genindex.html" title="General Index" accesskey="I">index</a></li> <li class="right" > <a href="installation.html" title="Installation and Status" accesskey="N">next</a> |</li> <li class="right" > <a href="index.html" title="CFFI documentation" accesskey="P">previous</a> |</li> <li><a href="index.html">CFFI 1.9.1 documentation</a> »</li> </ul> </div> <div class="document"> <div class="documentwrapper"> <div class="bodywrapper"> <div class="body"> <div class="section" id="what-s-new"> <h1>What’s New<a class="headerlink" href="#what-s-new" title="Permalink to this headline">¶</a></h1> <div class="section" id="v1-9"> <h2>v1.9<a class="headerlink" href="#v1-9" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Structs with variable-sized arrays as their last field: now we track the length of the array after <tt class="docutils literal"><span class="pre">ffi.new()</span></tt> is called, just like we always tracked the length of <tt class="docutils literal"><span class="pre">ffi.new("int[]",</span> <span class="pre">42)</span></tt>. This lets us detect out-of-range accesses to array items. This also lets us display a better <tt class="docutils literal"><span class="pre">repr()</span></tt>, and have the total size returned by <tt class="docutils literal"><span class="pre">ffi.sizeof()</span></tt> and <tt class="docutils literal"><span class="pre">ffi.buffer()</span></tt>. 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.)</li> <li>Add support in <tt class="docutils literal"><span class="pre">cdef()/set_source()</span></tt> for unspecified-length arrays in typedefs: <tt class="docutils literal"><span class="pre">typedef</span> <span class="pre">int</span> <span class="pre">foo_t[...];</span></tt>. It was already supported for global variables or structure fields.</li> <li>I turned in v1.8 a warning from <tt class="docutils literal"><span class="pre">cffi/model.py</span></tt> into an error: <tt class="docutils literal"><span class="pre">'enum</span> <span class="pre">xxx'</span> <span class="pre">has</span> <span class="pre">no</span> <span class="pre">values</span> <span class="pre">explicitly</span> <span class="pre">defined:</span> <span class="pre">refusing</span> <span class="pre">to</span> <span class="pre">guess</span> <span class="pre">which</span> <span class="pre">integer</span> <span class="pre">type</span> <span class="pre">it</span> <span class="pre">is</span> <span class="pre">meant</span> <span class="pre">to</span> <span class="pre">be</span> <span class="pre">(unsigned/signed,</span> <span class="pre">int/long)</span></tt>. Now I’m turning it back to a warning again; it seems that guessing that the enum has size <tt class="docutils literal"><span class="pre">int</span></tt> is a 99%-safe bet. (But not 100%, so it stays as a warning.)</li> <li>Fix leaks in the code handling <tt class="docutils literal"><span class="pre">FILE</span> <span class="pre">*</span></tt> arguments. In CPython 3 there is a remaining issue that is hard to fix: if you pass a Python file object to a <tt class="docutils literal"><span class="pre">FILE</span> <span class="pre">*</span></tt> argument, then <tt class="docutils literal"><span class="pre">os.dup()</span></tt> 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 <tt class="docutils literal"><span class="pre">close()</span></tt>, 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 <tt class="docutils literal"><span class="pre">fdopen()</span></tt> from C (...via cffi).</li> </ul> </div> <div class="section" id="v1-8-3"> <h2>v1.8.3<a class="headerlink" href="#v1-8-3" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>When passing a <tt class="docutils literal"><span class="pre">void</span> <span class="pre">*</span></tt> argument to a function with a different pointer type, or vice-versa, the cast occurs automatically, like in C. The same occurs for initialization with <tt class="docutils literal"><span class="pre">ffi.new()</span></tt> and a few other places. However, I thought that <tt class="docutils literal"><span class="pre">char</span> <span class="pre">*</span></tt> had the same property—but I was mistaken. In C you get the usual warning if you try to give a <tt class="docutils literal"><span class="pre">char</span> <span class="pre">*</span></tt> to a <tt class="docutils literal"><span class="pre">char</span> <span class="pre">**</span></tt> argument, for example. Sorry about the confusion. This has been fixed in CFFI by giving for now a warning, too. It will turn into an error in a future version.</li> </ul> </div> <div class="section" id="v1-8-2"> <h2>v1.8.2<a class="headerlink" href="#v1-8-2" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Issue #283: fixed <tt class="docutils literal"><span class="pre">ffi.new()</span></tt> on structures/unions with nested anonymous structures/unions, when there is at least one union in the mix. When initialized with a list or a dict, it should now behave more closely like the <tt class="docutils literal"><span class="pre">{</span> <span class="pre">}</span></tt> syntax does in GCC.</li> </ul> </div> <div class="section" id="v1-8-1"> <h2>v1.8.1<a class="headerlink" href="#v1-8-1" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>CPython 3.x: experimental: the generated C extension modules now use the “limited API”, which means that, as a compiled .so/.dll, it should work directly on any version of CPython >= 3.2. The name produced by distutils is still version-specific. To get the version-independent name, you can rename it manually to <tt class="docutils literal"><span class="pre">NAME.abi3.so</span></tt>, or use the very recent setuptools 26.</li> <li>Added <tt class="docutils literal"><span class="pre">ffi.compile(debug=...)</span></tt>, similar to <tt class="docutils literal"><span class="pre">python</span> <span class="pre">setup.py</span> <span class="pre">build</span> <span class="pre">--debug</span></tt> but defaulting to True if we are running a debugging version of Python itself.</li> </ul> </div> <div class="section" id="v1-8"> <h2>v1.8<a class="headerlink" href="#v1-8" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Removed the restriction that <tt class="docutils literal"><span class="pre">ffi.from_buffer()</span></tt> cannot be used on byte strings. Now you can get a <tt class="docutils literal"><span class="pre">char</span> <span class="pre">*</span></tt> out of a byte string, which is valid as long as the string object is kept alive. (But don’t use it to <em>modify</em> the string object! If you need this, use <tt class="docutils literal"><span class="pre">bytearray</span></tt> or other official techniques.)</li> <li>PyPy 5.4 can now pass a byte string directly to a <tt class="docutils literal"><span class="pre">char</span> <span class="pre">*</span></tt> argument (in older versions, a copy would be made). This used to be a CPython-only optimization.</li> </ul> </div> <div class="section" id="v1-7"> <h2>v1.7<a class="headerlink" href="#v1-7" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li><tt class="docutils literal"><span class="pre">ffi.gc(p,</span> <span class="pre">None)</span></tt> removes the destructor on an object previously created by another call to <tt class="docutils literal"><span class="pre">ffi.gc()</span></tt></li> <li><tt class="docutils literal"><span class="pre">bool(ffi.cast("primitive</span> <span class="pre">type",</span> <span class="pre">x))</span></tt> now returns False if the value is zero (including <tt class="docutils literal"><span class="pre">-0.0</span></tt>), and True otherwise. Previously this would only return False for cdata objects of a pointer type when the pointer is NULL.</li> <li>bytearrays: <tt class="docutils literal"><span class="pre">ffi.from_buffer(bytearray-object)</span></tt> is now supported. (The reason it was not supported was that it was hard to do in PyPy, but it works since PyPy 5.3.) To call a C function with a <tt class="docutils literal"><span class="pre">char</span> <span class="pre">*</span></tt> argument from a buffer object—now including bytearrays—you write <tt class="docutils literal"><span class="pre">lib.foo(ffi.from_buffer(x))</span></tt>. Additionally, this is now supported: <tt class="docutils literal"><span class="pre">p[0:length]</span> <span class="pre">=</span> <span class="pre">bytearray-object</span></tt>. The problem with this was that a iterating over bytearrays gives <em>numbers</em> instead of <em>characters</em>. (Now it is implemented with just a memcpy, of course, not actually iterating over the characters.)</li> <li>C++: compiling the generated C code with C++ was supposed to work, but failed if you make use the <tt class="docutils literal"><span class="pre">bool</span></tt> type (because that is rendered as the C <tt class="docutils literal"><span class="pre">_Bool</span></tt> type, which doesn’t exist in C++).</li> <li><tt class="docutils literal"><span class="pre">help(lib)</span></tt> and <tt class="docutils literal"><span class="pre">help(lib.myfunc)</span></tt> now give useful information, as well as <tt class="docutils literal"><span class="pre">dir(p)</span></tt> where <tt class="docutils literal"><span class="pre">p</span></tt> is a struct or pointer-to-struct.</li> </ul> </div> <div class="section" id="v1-6"> <h2>v1.6<a class="headerlink" href="#v1-6" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li><a class="reference external" href="ref.html#ffi-list-types">ffi.list_types()</a></li> <li><a class="reference external" href="ref.html#ffi-unpack">ffi.unpack()</a></li> <li><a class="reference external" href="using.html#extern-python-c">extern “Python+C”</a></li> <li>in API mode, <tt class="docutils literal"><span class="pre">lib.foo.__doc__</span></tt> contains the C signature now. On CPython you can say <tt class="docutils literal"><span class="pre">help(lib.foo)</span></tt>, but for some reason <tt class="docutils literal"><span class="pre">help(lib)</span></tt> (or <tt class="docutils literal"><span class="pre">help(lib.foo)</span></tt> on PyPy) is still useless; I haven’t yet figured out the hacks needed to convince <tt class="docutils literal"><span class="pre">pydoc</span></tt> to show more. (You can use <tt class="docutils literal"><span class="pre">dir(lib)</span></tt> but it is not most helpful.)</li> <li>Yet another attempt at robustness of <tt class="docutils literal"><span class="pre">ffi.def_extern()</span></tt> against CPython’s interpreter shutdown logic.</li> </ul> </div> <div class="section" id="v1-5-2"> <h2>v1.5.2<a class="headerlink" href="#v1-5-2" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Fix 1.5.1 for Python 2.6.</li> </ul> </div> <div class="section" id="v1-5-1"> <h2>v1.5.1<a class="headerlink" href="#v1-5-1" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>A few installation-time tweaks (thanks Stefano!)</li> <li>Issue #245: Win32: <tt class="docutils literal"><span class="pre">__stdcall</span></tt> was never generated for <tt class="docutils literal"><span class="pre">extern</span> <span class="pre">"Python"</span></tt> functions</li> <li>Issue #246: trying to be more robust against CPython’s fragile interpreter shutdown logic</li> </ul> </div> <div class="section" id="v1-5-0"> <h2>v1.5.0<a class="headerlink" href="#v1-5-0" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Support for <a class="reference external" href="embedding.html">using CFFI for embedding</a>.</li> </ul> </div> <div class="section" id="v1-4-2"> <h2>v1.4.2<a class="headerlink" href="#v1-4-2" title="Permalink to this headline">¶</a></h2> <p>Nothing changed from v1.4.1.</p> </div> <div class="section" id="v1-4-1"> <h2>v1.4.1<a class="headerlink" href="#v1-4-1" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Fix the compilation failure of cffi on CPython 3.5.0. (3.5.1 works; some detail changed that makes some underscore-starting macros disappear from view of extension modules, and I worked around it, thinking it changed in all 3.5 versions—but no: it was only in 3.5.1.)</li> </ul> </div> <div class="section" id="v1-4-0"> <h2>v1.4.0<a class="headerlink" href="#v1-4-0" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>A <a class="reference external" href="using.html#extern-python">better way to do callbacks</a> has been added (faster and more portable, and usually cleaner). It is a mechanism for the out-of-line API mode that replaces the dynamic creation of callback objects (i.e. C functions that invoke Python) with the static declaration in <tt class="docutils literal"><span class="pre">cdef()</span></tt> of which callbacks are needed. This is more C-like, in that you have to structure your code around the idea that you get a fixed number of function pointers, instead of creating them on-the-fly.</li> <li><tt class="docutils literal"><span class="pre">ffi.compile()</span></tt> now takes an optional <tt class="docutils literal"><span class="pre">verbose</span></tt> argument. When <tt class="docutils literal"><span class="pre">True</span></tt>, distutils prints the calls to the compiler.</li> <li><tt class="docutils literal"><span class="pre">ffi.compile()</span></tt> used to fail if given <tt class="docutils literal"><span class="pre">sources</span></tt> with a path that includes <tt class="docutils literal"><span class="pre">".."</span></tt>. Fixed.</li> <li><tt class="docutils literal"><span class="pre">ffi.init_once()</span></tt> added. See <a class="reference external" href="ref.html#ffi-init-once">docs</a>.</li> <li><tt class="docutils literal"><span class="pre">dir(lib)</span></tt> now works on libs returned by <tt class="docutils literal"><span class="pre">ffi.dlopen()</span></tt> too.</li> <li>Cleaned up and modernized the content of the <tt class="docutils literal"><span class="pre">demo</span></tt> subdirectory in the sources (thanks matti!).</li> <li><tt class="docutils literal"><span class="pre">ffi.new_handle()</span></tt> is now guaranteed to return unique <tt class="docutils literal"><span class="pre">void</span> <span class="pre">*</span></tt> values, even if called twice on the same object. Previously, in that case, CPython would return two <tt class="docutils literal"><span class="pre">cdata</span></tt> objects with the same <tt class="docutils literal"><span class="pre">void</span> <span class="pre">*</span></tt> value. This change is useful to add and remove handles from a global dict (or set) without worrying about duplicates. It already used to work like that on PyPy. <em>This change can break code that used to work on CPython by relying on the object to be kept alive by other means than keeping the result of ffi.new_handle() alive.</em> (The corresponding <a class="reference external" href="ref.html#ffi-new-handle">warning in the docs</a> of <tt class="docutils literal"><span class="pre">ffi.new_handle()</span></tt> has been here since v0.8!)</li> </ul> </div> <div class="section" id="v1-3-1"> <h2>v1.3.1<a class="headerlink" href="#v1-3-1" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>The optional typedefs (<tt class="docutils literal"><span class="pre">bool</span></tt>, <tt class="docutils literal"><span class="pre">FILE</span></tt> and all Windows types) were not always available from out-of-line FFI objects.</li> <li>Opaque enums are phased out from the cdefs: they now give a warning, instead of (possibly wrongly) being assumed equal to <tt class="docutils literal"><span class="pre">unsigned</span> <span class="pre">int</span></tt>. Please report if you get a reasonable use case for them.</li> <li>Some parsing details, notably <tt class="docutils literal"><span class="pre">volatile</span></tt> is passed along like <tt class="docutils literal"><span class="pre">const</span></tt> and <tt class="docutils literal"><span class="pre">restrict</span></tt>. Also, older versions of pycparser mis-parse some pointer-to-pointer types like <tt class="docutils literal"><span class="pre">char</span> <span class="pre">*</span> <span class="pre">const</span> <span class="pre">*</span></tt>: the “const” ends up at the wrong place. Added a workaround.</li> </ul> </div> <div class="section" id="v1-3-0"> <h2>v1.3.0<a class="headerlink" href="#v1-3-0" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Added <a class="reference external" href="ref.html#ffi-memmove">ffi.memmove()</a>.</li> <li>Pull request #64: out-of-line API mode: we can now declare floating-point types with <tt class="docutils literal"><span class="pre">typedef</span> <span class="pre">float...</span> <span class="pre">foo_t;</span></tt>. This only works if <tt class="docutils literal"><span class="pre">foo_t</span></tt> is a float or a double, not <tt class="docutils literal"><span class="pre">long</span> <span class="pre">double</span></tt>.</li> <li>Issue #217: fix possible unaligned pointer manipulation, which crashes on some architectures (64-bit, non-x86).</li> <li>Issues #64 and #126: when using <tt class="docutils literal"><span class="pre">set_source()</span></tt> or <tt class="docutils literal"><span class="pre">verify()</span></tt>, the <tt class="docutils literal"><span class="pre">const</span></tt> and <tt class="docutils literal"><span class="pre">restrict</span></tt> keywords are copied from the cdef to the generated C code; this fixes warnings by the C compiler. It also fixes corner cases like <tt class="docutils literal"><span class="pre">typedef</span> <span class="pre">const</span> <span class="pre">int</span> <span class="pre">T;</span> <span class="pre">T</span> <span class="pre">a;</span></tt> which would previously not consider <tt class="docutils literal"><span class="pre">a</span></tt> as a constant. (The cdata objects themselves are never <tt class="docutils literal"><span class="pre">const</span></tt>.)</li> <li>Win32: support for <tt class="docutils literal"><span class="pre">__stdcall</span></tt>. For callbacks and function pointers; regular C functions still don’t need to have their <a class="reference external" href="using.html#windows-calling-conventions">calling convention</a> declared.</li> <li>Windows: CPython 2.7 distutils doesn’t work with Microsoft’s official Visual Studio for Python, and I’m told this is <a class="reference external" href="https://bugs.python.org/issue23246">not a bug</a>. For ffi.compile(), we <a class="reference external" href="https://bitbucket.org/cffi/cffi/pull-requests/65/remove-_hack_at_distutils-which-imports/diff">removed a workaround</a> that was inside cffi but which had unwanted side-effects. Try saying <tt class="docutils literal"><span class="pre">import</span> <span class="pre">setuptools</span></tt> first, which patches distutils...</li> </ul> </div> <div class="section" id="v1-2-1"> <h2>v1.2.1<a class="headerlink" href="#v1-2-1" title="Permalink to this headline">¶</a></h2> <p>Nothing changed from v1.2.0.</p> </div> <div class="section" id="v1-2-0"> <h2>v1.2.0<a class="headerlink" href="#v1-2-0" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Out-of-line mode: <tt class="docutils literal"><span class="pre">int</span> <span class="pre">a[][...];</span></tt> can be used to declare a structure field or global variable which is, simultaneously, of total length unknown to the C compiler (the <tt class="docutils literal"><span class="pre">a[]</span></tt> part) and each element is itself an array of N integers, where the value of N <em>is</em> known to the C compiler (the <tt class="docutils literal"><span class="pre">int</span></tt> and <tt class="docutils literal"><span class="pre">[...]</span></tt> parts around it). Similarly, <tt class="docutils literal"><span class="pre">int</span> <span class="pre">a[5][...];</span></tt> is supported (but probably less useful: remember that in C it means <tt class="docutils literal"><span class="pre">int</span> <span class="pre">(a[5])[...];</span></tt>).</li> <li>PyPy: the <tt class="docutils literal"><span class="pre">lib.some_function</span></tt> objects were missing the attributes <tt class="docutils literal"><span class="pre">__name__</span></tt>, <tt class="docutils literal"><span class="pre">__module__</span></tt> and <tt class="docutils literal"><span class="pre">__doc__</span></tt> that are expected e.g. by some decorators-management functions from <tt class="docutils literal"><span class="pre">functools</span></tt>.</li> <li>Out-of-line API mode: you can now do <tt class="docutils literal"><span class="pre">from</span> <span class="pre">_example.lib</span> <span class="pre">import</span> <span class="pre">x</span></tt> to import the name <tt class="docutils literal"><span class="pre">x</span></tt> from <tt class="docutils literal"><span class="pre">_example.lib</span></tt>, even though the <tt class="docutils literal"><span class="pre">lib</span></tt> object is not a standard module object. (Also works in <tt class="docutils literal"><span class="pre">from</span> <span class="pre">_example.lib</span> <span class="pre">import</span> <span class="pre">*</span></tt>, but this is even more of a hack and will fail if <tt class="docutils literal"><span class="pre">lib</span></tt> happens to declare a name called <tt class="docutils literal"><span class="pre">__all__</span></tt>. Note that <tt class="docutils literal"><span class="pre">*</span></tt> excludes the global variables; only the functions and constants make sense to import like this.)</li> <li><tt class="docutils literal"><span class="pre">lib.__dict__</span></tt> works again and gives you a copy of the dict—assuming that <tt class="docutils literal"><span class="pre">lib</span></tt> has got no symbol called precisely <tt class="docutils literal"><span class="pre">__dict__</span></tt>. (In general, it is safer to use <tt class="docutils literal"><span class="pre">dir(lib)</span></tt>.)</li> <li>Out-of-line API mode: global variables are now fetched on demand at every access. It fixes issue #212 (Windows DLL variables), and also allows variables that are defined as dynamic macros (like <tt class="docutils literal"><span class="pre">errno</span></tt>) or <tt class="docutils literal"><span class="pre">__thread</span></tt> -local variables. (This change might also tighten the C compiler’s check on the variables’ type.)</li> <li>Issue #209: dereferencing NULL pointers now raises RuntimeError instead of segfaulting. Meant as a debugging aid. The check is only for NULL: if you dereference random or dead pointers you might still get segfaults.</li> <li>Issue #152: <a class="reference external" href="using.html#callbacks">callbacks</a>: added an argument <tt class="docutils literal"><span class="pre">ffi.callback(...,</span> <span class="pre">onerror=...)</span></tt>. If the main callback function raises an exception and <tt class="docutils literal"><span class="pre">onerror</span></tt> is provided, then <tt class="docutils literal"><span class="pre">onerror(exception,</span> <span class="pre">exc_value,</span> <span class="pre">traceback)</span></tt> is called. This is similar to writing a <tt class="docutils literal"><span class="pre">try:</span> <span class="pre">except:</span></tt> in the main callback function, but in some cases (e.g. a signal) an exception can occur at the very start of the callback function—before it had time to enter the <tt class="docutils literal"><span class="pre">try:</span> <span class="pre">except:</span></tt> block.</li> <li>Issue #115: added <tt class="docutils literal"><span class="pre">ffi.new_allocator()</span></tt>, which officializes support for <a class="reference external" href="ref.html#ffi-new-allocator">alternative allocators</a>.</li> </ul> </div> <div class="section" id="v1-1-2"> <h2>v1.1.2<a class="headerlink" href="#v1-1-2" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li><tt class="docutils literal"><span class="pre">ffi.gc()</span></tt>: fixed a race condition in multithreaded programs introduced in 1.1.1</li> </ul> </div> <div class="section" id="v1-1-1"> <h2>v1.1.1<a class="headerlink" href="#v1-1-1" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Out-of-line mode: <tt class="docutils literal"><span class="pre">ffi.string()</span></tt>, <tt class="docutils literal"><span class="pre">ffi.buffer()</span></tt> and <tt class="docutils literal"><span class="pre">ffi.getwinerror()</span></tt> didn’t accept their arguments as keyword arguments, unlike their in-line mode equivalent. (It worked in PyPy.)</li> <li>Out-of-line ABI mode: documented a <a class="reference external" href="cdef.html#dlopen-note">restriction</a> of <tt class="docutils literal"><span class="pre">ffi.dlopen()</span></tt> when compared to the in-line mode.</li> <li><tt class="docutils literal"><span class="pre">ffi.gc()</span></tt>: when called several times with equal pointers, it was accidentally registering only the last destructor, or even none at all depending on details. (It was correctly registering all of them only in PyPy, and only with the out-of-line FFIs.)</li> </ul> </div> <div class="section" id="v1-1-0"> <h2>v1.1.0<a class="headerlink" href="#v1-1-0" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Out-of-line API mode: we can now declare integer types with <tt class="docutils literal"><span class="pre">typedef</span> <span class="pre">int...</span> <span class="pre">foo_t;</span></tt>. The exact size and signedness of <tt class="docutils literal"><span class="pre">foo_t</span></tt> is figured out by the compiler.</li> <li>Out-of-line API mode: we can now declare multidimensional arrays (as fields or as globals) with <tt class="docutils literal"><span class="pre">int</span> <span class="pre">n[...][...]</span></tt>. Before, only the outermost dimension would support the <tt class="docutils literal"><span class="pre">...</span></tt> syntax.</li> <li>Out-of-line ABI mode: we now support any constant declaration, instead of only integers whose value is given in the cdef. Such “new” constants, i.e. either non-integers or without a value given in the cdef, must correspond to actual symbols in the lib. At runtime they are looked up the first time we access them. This is useful if the library defines <tt class="docutils literal"><span class="pre">extern</span> <span class="pre">const</span> <span class="pre">sometype</span> <span class="pre">somename;</span></tt>.</li> <li><tt class="docutils literal"><span class="pre">ffi.addressof(lib,</span> <span class="pre">"func_name")</span></tt> now returns a regular cdata object of type “pointer to function”. You can use it on any function from a library in API mode (in ABI mode, all functions are already regular cdata objects). To support this, you need to recompile your cffi modules.</li> <li>Issue #198: in API mode, if you declare constants of a <tt class="docutils literal"><span class="pre">struct</span></tt> type, what you saw from lib.CONSTANT was corrupted.</li> <li>Issue #196: <tt class="docutils literal"><span class="pre">ffi.set_source("package._ffi",</span> <span class="pre">None)</span></tt> would incorrectly generate the Python source to <tt class="docutils literal"><span class="pre">package._ffi.py</span></tt> instead of <tt class="docutils literal"><span class="pre">package/_ffi.py</span></tt>. Also fixed: in some cases, if the C file was in <tt class="docutils literal"><span class="pre">build/foo.c</span></tt>, the .o file would be put in <tt class="docutils literal"><span class="pre">build/build/foo.o</span></tt>.</li> </ul> </div> <div class="section" id="v1-0-3"> <h2>v1.0.3<a class="headerlink" href="#v1-0-3" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Same as 1.0.2, apart from doc and test fixes on some platforms.</li> </ul> </div> <div class="section" id="v1-0-2"> <h2>v1.0.2<a class="headerlink" href="#v1-0-2" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>Variadic C functions (ending in a ”...” argument) were not supported in the out-of-line ABI mode. This was a bug—there was even a (non-working) <a class="reference external" href="overview.html#out-of-line-abi-level">example</a> doing exactly that!</li> </ul> </div> <div class="section" id="v1-0-1"> <h2>v1.0.1<a class="headerlink" href="#v1-0-1" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li><tt class="docutils literal"><span class="pre">ffi.set_source()</span></tt> crashed if passed a <tt class="docutils literal"><span class="pre">sources=[..]</span></tt> argument. Fixed by chrippa on pull request #60.</li> <li>Issue #193: if we use a struct between the first cdef() where it is declared and another cdef() where its fields are defined, then this definition was ignored.</li> <li>Enums were buggy if you used too many ”...” in their definition.</li> </ul> </div> <div class="section" id="v1-0-0"> <h2>v1.0.0<a class="headerlink" href="#v1-0-0" title="Permalink to this headline">¶</a></h2> <ul class="simple"> <li>The main news item is out-of-line module generation:<ul> <li><a class="reference external" href="overview.html#out-of-line-abi-level">for ABI level</a>, with <tt class="docutils literal"><span class="pre">ffi.dlopen()</span></tt></li> <li><a class="reference external" href="overview.html#out-of-line-api-level">for API level</a>, which used to be with <tt class="docutils literal"><span class="pre">ffi.verify()</span></tt>, now deprecated</li> </ul> </li> <li>(this page will list what is new from all versions from 1.0.0 forward.)</li> </ul> </div> </div> </div> </div> </div> <div class="sphinxsidebar"> <div class="sphinxsidebarwrapper"> <h3><a href="index.html">Table Of Contents</a></h3> <ul> <li><a class="reference internal" href="#">What’s New</a><ul> <li><a class="reference internal" href="#v1-9">v1.9</a></li> <li><a class="reference internal" href="#v1-8-3">v1.8.3</a></li> <li><a class="reference internal" href="#v1-8-2">v1.8.2</a></li> <li><a class="reference internal" href="#v1-8-1">v1.8.1</a></li> <li><a class="reference internal" href="#v1-8">v1.8</a></li> <li><a class="reference internal" href="#v1-7">v1.7</a></li> <li><a class="reference internal" href="#v1-6">v1.6</a></li> <li><a class="reference internal" href="#v1-5-2">v1.5.2</a></li> <li><a class="reference internal" href="#v1-5-1">v1.5.1</a></li> <li><a class="reference internal" href="#v1-5-0">v1.5.0</a></li> <li><a class="reference internal" href="#v1-4-2">v1.4.2</a></li> <li><a class="reference internal" href="#v1-4-1">v1.4.1</a></li> <li><a class="reference internal" href="#v1-4-0">v1.4.0</a></li> <li><a class="reference internal" href="#v1-3-1">v1.3.1</a></li> <li><a class="reference internal" href="#v1-3-0">v1.3.0</a></li> <li><a class="reference internal" href="#v1-2-1">v1.2.1</a></li> <li><a class="reference internal" href="#v1-2-0">v1.2.0</a></li> <li><a class="reference internal" href="#v1-1-2">v1.1.2</a></li> <li><a class="reference internal" href="#v1-1-1">v1.1.1</a></li> <li><a class="reference internal" href="#v1-1-0">v1.1.0</a></li> <li><a class="reference internal" href="#v1-0-3">v1.0.3</a></li> <li><a class="reference internal" href="#v1-0-2">v1.0.2</a></li> <li><a class="reference internal" href="#v1-0-1">v1.0.1</a></li> <li><a class="reference internal" href="#v1-0-0">v1.0.0</a></li> </ul> </li> </ul> <h4>Previous topic</h4> <p class="topless"><a href="index.html" title="previous chapter">CFFI documentation</a></p> <h4>Next topic</h4> <p class="topless"><a href="installation.html" title="next chapter">Installation and Status</a></p> <h3>This Page</h3> <ul class="this-page-menu"> <li><a href="_sources/whatsnew.txt" rel="nofollow">Show Source</a></li> </ul> <div id="searchbox" style="display: none"> <h3>Quick search</h3> <form class="search" action="search.html" method="get"> <input type="text" name="q" /> <input type="submit" value="Go" /> <input type="hidden" name="check_keywords" value="yes" /> <input type="hidden" name="area" value="default" /> </form> <p class="searchtip" style="font-size: 90%"> Enter search terms or a module, class or function name. </p> </div> <script type="text/javascript">$('#searchbox').show(0);</script> </div> </div> <div class="clearer"></div> </div> <div class="related"> <h3>Navigation</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="genindex.html" title="General Index" >index</a></li> <li class="right" > <a href="installation.html" title="Installation and Status" >next</a> |</li> <li class="right" > <a href="index.html" title="CFFI documentation" >previous</a> |</li> <li><a href="index.html">CFFI 1.9.1 documentation</a> »</li> </ul> </div> <div class="footer"> © Copyright 2012-2015, Armin Rigo, Maciej Fijalkowski. Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3. </div> </body> </html>