[pypy-commit] cffi default: hg merge release-1.10

arigo pypy.commits at gmail.com
Tue Mar 21 06:43:13 EDT 2017


Author: Armin Rigo <arigo at tunes.org>
Branch: 
Changeset: r2919:486d919c0b87
Date: 2017-03-21 11:42 +0100
http://bitbucket.org/cffi/cffi/changeset/486d919c0b87/

Log:	hg merge release-1.10

diff --git a/doc/source/installation.rst b/doc/source/installation.rst
--- a/doc/source/installation.rst
+++ b/doc/source/installation.rst
@@ -53,11 +53,11 @@
 
 * http://pypi.python.org/packages/source/c/cffi/cffi-1.10.0.tar.gz
 
-   - MD5: ...
+   - MD5: 2b5fa41182ed0edaf929a789e602a070
 
-   - SHA: ...
+   - SHA: 8484aba03d1e64367d3110c0e36c1ed052b43f12
 
-   - SHA256: ...
+   - SHA256: b3b02911eb1f6ada203b0763ba924234629b51586f72a21faacc638269f4ced5
 
 * Or grab the most current version from the `Bitbucket page`_:
   ``hg clone https://bitbucket.org/cffi/cffi``
diff --git a/doc/source/whatsnew.rst b/doc/source/whatsnew.rst
--- a/doc/source/whatsnew.rst
+++ b/doc/source/whatsnew.rst
@@ -9,18 +9,16 @@
 * 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.  (But avoid doing that too often:
-  on 32-bit PyPy it will quickly exhaust the address space.  If possible,
-  use instead explicit calls to calloc() and free().)
+  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" (not a struct *pointer*).
+  complicated" (and not a struct *pointer*, which always works).
 
-* Add support for some obscure compilers (non-msvc, non-gcc, non-icc,
+* Add support for some unusual compilers (non-msvc, non-gcc, non-icc,
   non-clang)
 
 * Implemented the remaining cases for ``ffi.from_buffer``.  Now all
@@ -33,15 +31,15 @@
 
 * 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
-  change here is mostly what occurs if the byte happens to contain a
+  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.
+  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 on the first zero).
+  ``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.
@@ -61,6 +59,11 @@
   "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.
+
 
 v1.9
 ====


More information about the pypy-commit mailing list