Given that the `ZEND_AST_OP_ARRAY` type already needed special handling in
various places, it makes sense to give it its own struct to avoid some of the
casts. As a side benefit, it is a little smaller than the `zend_ast_zval`
struct.
The description of PHP_STRLCPY says that this is a fast version of strlcpy that should be used if we *know* the size of both the source and destination buffers.
This is clearly not the case as we use strlen() to compute it.
Moreover if the result cannot fit in the destination buffer something seriously strange has happened and we should return a failure state rather than truncating.
`glob(3)` doesn't know the virtual CWD of PHP, so we need to pass an
absolute path for ZTS builds. In lack of a reusable routine, we copy
the code from `glob()` and adapt as needed.
Closes GH-17074.
The "else branch" of `next_line` can reset the `buf_begin` field to
NULL, causing the next invocation to pass NULL to `memchr` with a 0
length. When UBSAN is enabled this causes an UBSAN abort. Real world
impact is likely none because of the 0 length.
To fix this, don't set the pointer to NULL, which means that the
`memchr` will return NULL and since
`self->bytes_in_buffer < self->bufsize` we return NULL and request more
data through `fill_buffer`. That function will reset `buf_begin` and
`bytes_in_buffer` so that the next invocation works fine.
I chose this solution so we have an invariant that `buf_begin` is never
NULL, which makes reasoning easier. An alternative solution is keeping
the NULLing of `buf_begin` and add an extra check at the top of
`next_line`, but I didn't like special casing this.
Closes GH-17000.
When connecting to socket, it is possible to get EINTR. In such case,
there should be an another attempt to connect if we are not over the
timeout. The timeout should be adjusted accordingly in that case.
This fixes https://github.com/phpredis/phpredis/issues/1881
Closes GH-16606
If `_DEBUG` is set, assertion failures and errors are directed to a
debug message window by default[1]. That causes a process to hang,
since these dialogs are modal. While we already cater to assertion
failures, errors have apparently been overlooked.
We choose a minimal fix for BC reasons; although passing `0` as
`reportMode` is undocumented, it obviously works fine for a long time.
We may consider to improve on this for the `master` branch.
[1] <https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/crtsetreportmode>
Closes GH-16850.
This information can be occasionally useful, and would otherwise need
to be parsed from `phpinfo()` output.
However, maybe more importantly we unify the build date between what is
given by `php -v` and `php -i`, since these compilation units are not
necessarily preprocessed within the same second.
Closes GH-16747.
* Don't fiddle with NDEBUG in C code
It is way to late to do this in php.h, since assert.h has already been
included. Even pushing that down to zend_portability.h may not have
the desired effect. Instead we define or undefine NDEBUG as CFLAG, so
that it works in all circumstances.
As a last resort we fail at build time, if `NDEBUG` is defined when
`ZEND_DEBUG` is enabled.
We also remove the useless workaround in zend_test to include assert.h
again, since that usually won't have any effect anyway.
Co-authored-by: Arnaud Le Blanc <arnaud.lb@gmail.com>
As is, for requested size which are already aligned, we over-allocate,
so we fix this. We also fix the allocation for chunk size 1.
This issue has been reported by @kkmuffme.
Thanks to @iluuu1994 for improving the fix!
Closes GH-16161.
For `zend_string` pointers in class entries, show the string contents (if not
`NULL`).
For class constants, the `ce` (class entry pointer) field is shown with the
name of the class, and the `doc_comment` field is shown with the string
contents if possible.
Both macros are supposed to be defined in limits.h (C99) and as such it
is superfluous to provide fallback definitions. Even worse, because
these fallback definitions didn't cater to LP64, ILP64 and SILP64 data
models (and maybe some rather uncommon ones), but just assumed ILP32,
they are confusing.
