[PHP-DEV] Small annoyances of PHP: Simple fixes would make tests fail

[Christian Schneider]

Hi there,
we encountered small annoyances over time which could be easy to fix but would 
break tests.
Why does this matter? While it is easy to fix the PHP test suite they could 
potentially affect other projects' code, most probably tests.

Here are the two things on our current list:

Stack traces:
==
Stack traces for certain constructs do not include the exact location in the 
stack frame:
$a[(object)null] = 1;
$e->getTrace() => []# <-- no stack trace
while for
file(); / file(null);
$e->getTrace() => [ ["file"]=> .. ].

The change would probably be something like removing one line
ptr = ptr->prev_execute_data;
In Zend/zend_builtin_functions.c

The BC impact Is that stack traces may contain an additional entry which is 
used in a lot of tests.

Work-around: Our solution right now is to manually check in the exception 
handler whether $e->getFile() / $e->getLine() is already contained in 
$e->getTrace()[0] and otherwise add it to have uniform stack traces. Works, but 
ugly :-)

Indentation in var_export:

The indentation for
var_export((object)[(object)[]]);
is off by one for nested structures:
(object) array(
   '0' =>   # <-- extra space before index
  (object) array(
and the fix would be to change
buffer_append_spaces(buf, level + 2)
to
buffer_append_spaces(buf, level + 1)
in ext/standard/var.c

This breaks about 60 PHP tests relying on the var_export format.

We were hoping for a new function mitigating this issue but 
https://wiki.php.net/rfc/readable_var_representation 
 seems to get rejected so 
the issue remains :-)

---

Is there any way something like there things could/should be tackled for a 
future PHP version?
I'm torn because of the impact vs. benefit of the improvements.

- Chris

Re: [PHP-DEV] Small annoyances of PHP: Simple fixes would make tests fail

[Sara Golemon]

On Fri, Feb 19, 2021 at 8:04 AM Christian Schneider 
wrote:

> Hi there,
> we encountered small annoyances over time which could be easy to fix but
> would break tests.
> Why does this matter? While it is easy to fix the PHP test suite they
> could potentially affect other projects' code, most probably tests.
>
> Here are the two things on our current list:
>
> Stack traces:
> ==
> Stack traces for certain constructs do not include the exact location in
> the stack frame:
> $a[(object)null] = 1;
> $e->getTrace() => []# <-- no stack trace
> while for
> file(); / file(null);
> $e->getTrace() => [ ["file"]=> .. ].
>
>
What version are you testing with. I know Niki killed some unnecessary
frames in 8.0's stacktrace output. (A whole repro script is more useful
than a snippet wherein $e comes into being seemingly from nowhere).



> Indentation in var_export:
> 
> The indentation for
> var_export((object)[(object)[]]);
> is off by one for nested structures:
> (object) array(
>'0' =>   # <-- extra space before index
>   (object) array(
> and the fix would be to change
> buffer_append_spaces(buf, level + 2)
> to
> buffer_append_spaces(buf, level + 1)
> in ext/standard/var.c
>
> This breaks about 60 PHP tests relying on the var_export format.
>
>
I think shifting the indentation in var_export() could probably be done
without a major BC break.  Trimming trailing whitespace would also resolve
one of my long-time annoyances with the function.
Feel free to propose that as a PR and/or an RFC.

-Sara

[PHP-DEV] Re: Potential RFC around PDO

[Christoph M. Becker]

Hi Daniel!

On 18.02.2021 at 01:57, Daniel Beardsley wrote:

> wiki username: danielbeardsley
>
> === Background
> I was told to introduce myself. I've been in software development for more
> than 20 years and have been working with php for 10 or so of that. I've
> only had a little contact with this group, but I've got at least one past
> pull merged on the php-src repo: https://github.com/php/php-src/pull/271.
> At iFixit we use a forked version of php with a small change to allow
> automatically html-escaping echoed strings:
> https://github.com/iFixit/php-src/commit/cb6eb5c35a07c843e5b357884186d77e3a1a2981
> . It's not something this list would be interested in as it's rather
> special-purpose, but I'm mentioning it to show I'm somewhat familiar with
> the php build system.
>
> === Why I'm emailing now:
> I've opened a pull request on php-src:
> https://github.com/php/php-src/pull/6677 and I've been advised to make an
> RFC. The first step is emailing!
>
> I'd like to propose adding a function to the mysql pdo driver (in the same
> way postgres and sqlite have) to extract the count of warnings from the
> last executed statement.
>
> See the pull request linked above for a more thorough description.
>
> Should I make an RFC out of this?

Yes, I think this needs an RFC, because adding driver specific methods
is rather controversial.  See e.g. .

Anyhow, RFC karma has been granted.

--
Christoph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php