We mark symlink_link_linkinfo_is_link_error2.phpt as XFAIL on Windows
ZTS. Several Windows API file system functions ignore trailing spaces
in absolute filenames after the final directory separator, which causes
`link(' ', $link)` to actually call `CreateHardLink()` which then
fails, because linking folders is not supported. However, with NTS
builds (as well as on other systems), the $target is found to not
exist, so the function fails without actually attempting to create the
link. This needs further investigation.
When performing an RW modification of an array offset, the undefined
offset warning may call an error handler / OB callback, which may
destroy the array we're supposed to change. Detect this by temporarily
incrementing the reference count. If we find that the array has been
modified/destroyed in the meantime, we do nothing -- the execution
model here would be that the modification has happened on the destroyed
version of the array.
In the interest of avoiding side-effects during dumping, I'm
replacing the value with a <constant ast> string instead of
performing an update constant operation.
We modify _basic1.phpt so it runs on Windows as well. The other test
cases hit the issue that `readlink()` fails normally for regular files,
but succeeds on Windows[1]. Therefore, we split these tests, but still
fix the skip reasons.
[1] <http://svn.php.net/viewvc?view=revision&revision=350097>
Most of these have been skipped on Windows for no good reason (`lstat`
is available there as of PHP 4). Several others would only fail,
because the `blksize` and `blocks` elements are always `-1` on Windows,
which can easily be fixed by using `%i` format specifiers instead of
`%d`.
Fixes a use-after-free encountered in Symfony's SecurityBundle.
I don't have a reproducer for this, and believe the issue can only
occur if we leak an iterator (the leak is a separate issue).
We should not free the generator iterator here, because we do not
own it. The code that fetched the iterator is responsible for
releasing it. In the rare case where we do hit this code-path,
we cause a use-after-free.
A `BSTR` is similar to a `zend_string`; it stores the length of the
string just before the actual string, and thus the string may contain
NUL bytes. However, `php_com_olestring_to_string()` is supposed to
deal with arbitrary `OLECHAR*`s which may not be `BSTR`s, so we
introduce `php_com_bstr_to_string()` and use it for the only case where
we actually have to deal with `BSTR`s which may contain NUL bytes.
Contrary to `php_com_olestring_to_string()` we return a `zend_string`,
so we can save the re-allocation when converting to a `zval`.
We also cater to `php_com_string_to_olestring()` not being binary safe,
with basically the same fix we did for `php_com_olestring_to_string()`.
