Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113212
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CC1BA4F3-EAAD-4C96-BD45-7109ED05A236"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Message-ID: <52E47CD0-11F0-45DF-9387-DFB5DFDC481A@cschneid.com>
Date: Fri, 19 Feb 2021 15:04:04 +0100
To: PHP internals <internals@lists.php.net>
Subject: Small annoyances of PHP: Simple fixes would make tests fail
From: cschneid@cschneid.com (Christian Schneider)

--Apple-Mail=_CC1BA4F3-EAAD-4C96-BD45-7109ED05A236
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

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:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Stack traces for certain constructs do not include the exact location in =
the stack frame:
	$a[(object)null] =3D 1;
	$e->getTrace() =3D> []		# <-- no stack trace
while for
	file(); / file(null);
	$e->getTrace() =3D> [ ["file"]=3D> .. ].

The change would probably be something like removing one line
	ptr =3D 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:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The indentation for
	var_export((object)[(object)[]]);
is off by one for nested structures:
	(object) array(
	   '0' =3D> 			# <-- 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 =
<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


--Apple-Mail=_CC1BA4F3-EAAD-4C96-BD45-7109ED05A236--