In practice almost nobody checks for failed allocation, including unfortunately
the serd tests and serdi itself. Adding a struct mode to conditionally define
this would be a good idea to support allocation-hardened code, but for now just
mark them as unspecified instead.
On the bright side, this documents the nature of the returned pointers nicely.
This is a bit unfortunate since they are quite useful as documentation, but
unfortunately Doxygen (as usual) doesn't manage to format things nicely, and
the noise makes the summaries unreadable.
This will warn if NULL is passed to any nonnull-annotated parameter, and is
also supported by sanitizers which can check for violations at runtime.
Unfortunately, it is currently only supported by clang. GCC has a similar
feature in the nonnull attribute, but this has a different syntax (it's a
function attribute) and is more dangerous since it is used by the optimizer to
assume a null pointer is undefined behavior. This one just warns and still
allows code to handle the situation gracefully, which I think is more
appropriate for a library API.
Note that this optimization behavior is not some unlikely edge case: switching
these attributes to the GCC one will break release builds.
In exchange for suppressing a pointless superficial warning instead, but I
dislike that convention since it looks confusing when hex digits are used and
it's inconsistent with near-universal floating point suffix convention.
This eliminates eat_byte() and the way it conflates the status of advancing the
source with the current character, which can cause problems with custom sinks.
This is a bit questionable, but the null byte support is needed for streaming
over a socket where some delimiter is required. This caused a bug where serdi
would hang forever on corrupt files that contain a null byte.
Fix this by consuming the byte, but otherwise behaving as before.
David Robillard