remove specialized printing from phpdbg

[krakjoe]

This quickly turned into a nightmare ... phpdbg is using bad format specifiers everywhere, and we got no warnings about it because they were disabled because of special format specifiers that phpdbg implemented ....

[krakjoe]

@nikic can you take a quick glance at this please ... it turned out much more involved than I would have liked. When I enabled format checking everything blew up ... it works now, but is there anything that could be obviously better ?

[krakjoe]

Damn it, no vasprintf on windows and 'p' looks broken in ap_php_*

@cmb69 any ideas ?

[nikic]

You're looking for a _phpdbg_asprintf replacement right? This looks the same as zend_spprintf to me (with the difference that spprintf uses per-request allocator).

[krakjoe]

@nikic the problem seems to be that whatever api we call we end up in format_converter, which has a broken 'p' specifier (unused in php-src, I think, so uncaught). I wish I'd noticed this 8 hours ago when I started.

My last commit makes the output correct, although some segv on windows doesn't necessarily look related ... so awaiting av run.

[nikic]

@krakjoe I see. %pd is a custom modifier for zend_long and just %p gets eaten as a modifier, even though it's supposed to be a specifier.

We stopped using %pd a long time ago in php-src so we can enable printf format checks. I'm a bit worried that extensions may be using it, but then those extensions must have been ignoring printf format warnings for years now, so I think it's okay to drop support.

[nikic]

Looks like the spprintf implementation actually handles this correctly:

php-src/main/spprintf.c

Lines 342 to 349 in 591dcdb

	char __next = *(fmt+1);
	if ('d' == __next || 'u' == __next || 'x' == __next || 'o' == __next) {
	fmt++;
	modifier = LM_PHP_INT_T;
	} else {
	modifier = LM_STD;
	}
	}

[nikic]

#7159 for a defensive approach to removing p support.

[krakjoe]

Rebased on #7159, thanks ... await CI ... should be good now, I think ...

[nikic]

Looks OK. I think we'd usually use uint32_t for linenos, but it doesn't really matter either way.

[nikic]

Just wondering why this is gone now?

[krakjoe]

We no longer write buffered (FILE*) streams anywhere, this looks like a left over relic rather than necessary.

[nikic]

Make sense.