This may have practical advantages when the zephyr header is otherwise quite long. It should have negligible functional impact, since current clients mostly ignore the field (paying attention to it is a security risk). The particular default format this uses is a link to a page that will explaining (for any clients that *do* show it) why they're seeing it and why that's bad, and is the same format used by barnowl and some other clients.
If we are holding onto the char* version of a PyObject*, we need to hold a reference to that PyObject itself. In CPython, the previous code generally works because the ZNotice object would hold a reference from __dict__. This assumption is not true in PyPy, and would also break in weirder cases like someone subclassing ZNotice and replacing 'cls' with a property. We can't just hold the objects in a Python list, because again, in PyPy, that results in conversion to PyPy's internal format, which does not hold onto the specific PyObject* generated by cpyext. So instead, write some C code to maintain an object pool of objects to which we need references.
Older clients have a tendency to send latin-1 on the wire, and the zephyr protocol itself does not require an explicit encoding. Therefore, make encoding and decoding the responsibility of the application using PyZephyr. (PyZephyr will to continue to encode a unicode string to UTF-8 before sending it if that is handed in) Reported-by: Arun A. Tharuvai <firstname.lastname@example.org>
Reported-by: Arun A. Tharuvai <email@example.com>
If code other than receive() ends up calling ZWaitForNotice or similar routines, then there may be zephyrs in the internal Zephyr queue, but no data available on the Zephyr FD. Therefore, before we assume we need to block to receive notices, we need to check ZPending() and process any queued notices.
The one in ZReceiveNotice times out eventually.
Signed-off-by: Anders Kaseorg <firstname.lastname@example.org>
Instead of using a function to convert between struct timeval and a Python float, inline the necessary code in the ZUid and ZNotice conversions. On 64-bit Debian systems, this would result in a struct _ZTimeval being cast to a struct timeval, which just didn't work like you would hope.
They use timeval instead. And Debian-based systems will work if you use timeval instead of _ZTimeval, they'll just whine at you