Having `int` there is no real profit in the size or speed, while unsigned
improves security and overall integration. ZPP supplied strings can
be then accepted directly and structs can be still handled with smaller
unsigned types for size reasons, which is safe. Yet some related places
are to go.
basic move tsrm_realpath_r to size_t
fix conditions and sync with affected places
touch ocurrences of php_sys_readlink usage
follow up on phar path handling
remove duplicated check
move zend_resolve_path and related pieces to size_t
touch yet resolve path related places
remove cast
missing pieces
missing piece
yet cleanups for php_sys_readlink for ssize_t
fix wrong return
Example (with v8js):
/builddir/build/BUILD/php-pecl-v8js-1.3.4/NTS/v8js_class.cc: In function 'void v8js_execute_script(zval*, v8js_script*, long int, long int, long int, zval**)':
/usr/include/php/Zend/zend.h:204:57: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
#define zend_bailout() _zend_bailout(__FILE__, __LINE__)
^
/builddir/build/BUILD/php-pecl-v8js-1.3.4/NTS/v8js_class.cc:633:3: note: in expansion of macro 'zend_bailout'
zend_bailout();
^~~~~~~~~~~~
vs(tr)pprintf is now implemented in Zend on top of
printf_to_smart_str(int), which is provided as a utility function.
This allows us to efficiently printf to the end of a smart string.
It's annoying that in Zend you have to use zend_strpprintf instead
of strpprintf, while in PHP you have to use strpprintf instead of
zend_strpprintf.
Make zend_s(tr)pprintf always available and keep s(tr)pprintf as
macro aliases.
Historicaly, these macros were introduced as a protection from execution timeout handling, but we don't need them anymore after "safe execution timeout" implementation.
These macros are still useful to protect from termination during inner process data modification, because of OS signals (e.g. SIGTERM during OPcache SHM update).
Instead of directly writing to stdout. This allows doing a print_r
into a string, without using output buffering.
The motivation for this is bug #67467: print_r() in return mode
will still dump the string to stdout (causing a potential information
leak) if a fatal error occurs.
This means we no longer allocate an unused VAR for the retval of
instructions that support unused results.
Nearly all instructions already used the result variable only if
it was used. The only exception to this was the return value
variable for internal function call results. I've adjusted the code
to use a stack zval for the unused return case now. As we have
retval specialization now, we know that it doesn't matter.
Introduces a ZEND_PARSE_PARAMS_THROW flag for zpp, which forces to
report FAILURE errors using a TypeException instead of a Warning,
like it would happen in strict mode.
Adds a zend_parse_parameters_throw() convenience function, which
invokes zpp with this flag.
Converts all cases I could identify, where we currently have
throwing zpp usage in constructors and replaces them with this API.
Error handling is still replaced to EH_THROW in some cases to handle
other, domain-specific errors in constructors.
actually, maybe we should precalculate before calling zend_hash_appen
when we are not sure whether the hash is caclculated(prop_info->name).
but it looks a little ugly.. (also for zend_string_copy)
