So we can use it there as well...
For now I've retained the zend_smart_str_public.h header, though
it would probably be better to just move that one struct into
zend_types.h.
smart_str_free_ex no longer exists, always use smart_str_free instead.
smart_str_alloc no longer requires a newlen variable to be in scope,
instead it returns the new length.
The data for messages of type SOL_SOCKET/SCM_RIGHTS was not being
passed correctly. There were actually two bugs: (1) the number of file
descriptors being passed was being read incorrectly (the length of the
cmsg array was being read instead of that of its 'data' element), as a
result it was generally being reported as always three elements
('level', 'type' and 'data') and (2) the allocated block for writing
the file descriptors was being acessed incorrectly because a 1-based
counter was being used as if it was 0-based.
Any of these two bugs would probably be enough to cause heap
corruption.
This reverts commit 61a5ec7381ba5388a52926779fe3f58af0caea83.
I checked Linux and OpenBSD and both use integers to write the
IPV6_TCLASS messages and they don't force any endianness. This is
despite RFC 3542 explicitly saying the first byte of cmsg_data will
have the result. In any case, it doesn't make any difference in
little-endian archs.
