forked from pool/python-cffi
Accepting request 480703 from devel:languages:python:singlespec
singlespec + version update OBS-URL: https://build.opensuse.org/request/show/480703 OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-cffi?expand=0&rev=31
This commit is contained in:
committed by
Git OBS Bridge
parent
68f8dd10a1
commit
3fb594641e
@@ -1,3 +1,82 @@
|
||||
-------------------------------------------------------------------
|
||||
Thu Mar 16 17:33:16 UTC 2017 - jmatejek@suse.com
|
||||
|
||||
- update to 1.9.1
|
||||
- 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).
|
||||
- When passing a void * 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 ffi.new() and a few other places. However, I
|
||||
thought that char * had the same property—but I was mistaken. In C you get
|
||||
the usual warning if you try to give a char * to a char ** 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.
|
||||
- Issue #283: fixed ffi.new() 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 { } syntax does in GCC.
|
||||
- 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 NAME.abi3.so, or use the very recent setuptools 26.
|
||||
- Added ffi.compile(debug=...), similar to python setup.py build --debug but
|
||||
defaulting to True if we are running a debugging version of Python itself.
|
||||
- Removed the restriction that ffi.from_buffer() cannot be used on byte
|
||||
strings. Now you can get a char * out of a byte string, which is valid as
|
||||
long as the string object is kept alive. (But don’t use it to modify the
|
||||
string object! If you need this, use bytearray or other official
|
||||
techniques.)
|
||||
- PyPy 5.4 can now pass a byte string directly to a char * argument (in older
|
||||
versions, a copy would be made). This used to be a CPython-only
|
||||
optimization.
|
||||
- ffi.gc(p, None) removes the destructor on an object previously created by
|
||||
another call to ffi.gc()
|
||||
- bool(ffi.cast("primitive type", x)) now returns False if the value is zero
|
||||
(including -0.0), and True otherwise. Previously this would only return
|
||||
False for cdata objects of a pointer type when the pointer is NULL.
|
||||
- bytearrays: ffi.from_buffer(bytearray-object) 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 char * argument from a buffer
|
||||
object—now including bytearrays—you write lib.foo(ffi.from_buffer(x)).
|
||||
Additionally, this is now supported: p[0:length] = bytearray-object. The
|
||||
problem with this was that a iterating over bytearrays gives numbers
|
||||
instead of characters. (Now it is implemented with just a memcpy, of
|
||||
course, not actually iterating over the characters.)
|
||||
- C++: compiling the generated C code with C++ was supposed to work, but
|
||||
failed if you make use the bool type (because that is rendered as the C
|
||||
_Bool type, which doesn’t exist in C++).
|
||||
- help(lib) and help(lib.myfunc) now give useful information, as well as
|
||||
dir(p) where p is a struct or pointer-to-struct.
|
||||
- drop upstreamed python-cffi-avoid-bitshifting-negative-int.patch
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Tue Dec 6 14:39:52 UTC 2016 - jmatejek@suse.com
|
||||
|
||||
- update for multipython build
|
||||
|
||||
-------------------------------------------------------------------
|
||||
Sun May 29 05:23:27 UTC 2016 - badshah400@gmail.com
|
||||
|
||||
|
||||
Reference in New Issue
Block a user