There are two issues to resolve:
1. The FCC is not refetch when trying to unregister a trampoline
2. Comparing the function pointer of trampolines is meaningless as they are reallocated, thus we need to compare the name of the function
Found while working on GH-8294
Closes GH-10033
We need to overwrite the __toString magic method for SplFileObject, similarly to how DirectoryIterator overwrites it
Moreover, the custom cast handler is useless as we define __toString methods, so use the standard one instead.
Closes GH-9912
First, we must not free the current line before we call
`spl_filesystem_file_read_csv()`, because then the `current_line` will
not be properly updated. Since the EOF check is superfluous here, we
move that part of the code to the branch for subtypes. This issue has
been introduced by the fix for bug 75917.
Second, we only must increase the `current_line` if we're not reading
ahead. This issue has been introduced by the fix for bug 62004.
Closes GH-8138.
While the `path` is not supposed to be `NULL` for normal operation, it
is possible to create `SplFileInfo` objects where that is the case, and
we must not follow the null pointer.
Closes GH-7814.
iterator_funcs_ptr may be null for Iterators with custom
get_iterator. Ideally MultipleIterator would make use of get_iterator,
but this would require a large implementation change.
We must not free the read line, if the `READ_AHEAD` flag is set. This
also restores the expectations of SplFileObject_next_variation002.phpt.
Closes GH-7518.
We address the `::setSize(0)` case by setting `array->element = NULL`
and `array->size = 0` before we destroy the elements.
Co-authored-by: Tyson Andre <tyson.andre@uwaterloo.ca>
Closes GH-7503.
offsetSet did not account for the fact that the array may no longer exist after
the field is overwritten. This fixes that.
Add test of resizing both to the empty array and a smaller array - there should
be no valgrind warnings with a proper fix.
Alternate approach to #7486 (described in https://bugs.php.net/bug.php?id=81429)
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.
* Move spl_offset_convert_to_long() to spl_fixedarray.c
It is only used there, which explains its weird offset semantics
* Refactor SplFixedArray offset handling
- Implement warning for resource type
- Throw a proper TypeError instead of a RuntimeException
* Use a proper Error to signal that [] cannot be used with SplFixedArray
* Refactor SplFixedArray has_dimension helper
* Drop some ZPP tests
