Both the documentation and the stubs state that this method is
supposed to return false on failure. However, if the line read
(rather than the getcsv operation) fails, it would incorrectly
return null instead.
I was trying to figure out when fgetcsv parsing can return false.
Apparently this can only happen if there is an unclosed enclosure
and no terminating newline -- why does the newline matter???
We must not assume that `usearch_last()` gives the proper result for
negative offsets. Instead we'd need to continue to search backwards
(`usearch_previous`) until we find a proper match. However, apparently
searching backwards is broken, so we work around by searching forward
from the start of the string until we pass the `offset_pos`, and then
use the previous result.
Closes GH-7189.
- Truncated multi-byte characters are treated as an error
- Truncated or unrecognized escape sequences are treated as an error
- ASCII control characters are not allowed to appear in the middle
of a multi-byte character
- Truncated multi-byte characters are treated as an error now
- Invalid multi-byte characters are treated as an error rather than
being quietly swallowed
- ASCII control characters are not allowed to appear in the middle
of a multi-byte character
As suggested on the patch discussion, adding init/end macros. Plus,
prefixed the new functions with php_ to avoid possible symbol conflicts.
Signed-off-by: Anatol Belski <ab@php.net>
TMPVAR operands are destroyed using zval_ptr_dtor_nogc(), because
they usually cannot contain cycles. However, there are some rare
exceptions where this is possible, e.g. unserialize() return value.
In such cases we rely on the producing code to root the value. If
a GC run occurs between the rooting and consumption of the value,
we would end up leaking it. To avoid this, root all live TMPVAR
values after a GC run.
Closes GH-7210.
tsrm_realpath() internally always allocates a string. If the out
parameter is provided it gets copied there and freed. What we
were doing here was to first copy the path from the allocated
string to a stack buffer, and then copy it from the stack buffer
to a zend_string. We might as well save one copy and one buffer.
The analysis in the bug report wasn't correct (at least not in
this case -- there may still be a more general problem here),
the issue was that write_property returned the original variable_ptr
rather than the zend_assign_to_variable() return value, which will
DEREF the variable before overwriting it.
