python3-cffi
No description set
- Sources inherited from project openSUSE:Leap:42.3
-
1
derived packages
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout openSUSE:Leap:42.3:Update/python3-cffi && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
cffi-1.9.1.tar.gz | 0000407108 398 KB | |
python3-cffi-doc.changes | 0000020039 19.6 KB | |
python3-cffi-doc.spec | 0000001455 1.42 KB | |
python3-cffi.changes | 0000020039 19.6 KB | |
python3-cffi.spec | 0000001929 1.88 KB |
Revision 4 (latest revision is 5)
Ludwig Nussel (lnussel_factory)
accepted
request 446585
from
Ondřej Súkup (mimi_vx)
(revision 4)
- update to version 1.9.1: (no changelog available) - changes from version 1.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).
Comments 0