On 06/07/2021 07:38, G. P. B. wrote:
This is I think the main issue with the current shape of the proposal.
This implementation will detect certain security issues, but finding the
root cause for them is going to be rather complicated, as the concatenation
operation is basically kicking the can down the road about the
responsibility of checking whether or not the result is a literal.
Whereas using a function like concat_literal() which checks that the inputs
are indeed literals provides immediate feedback that the type constraint is
not being violated.
I still don't follow this reasoning, for the reasons I outlined here:
https://externals.io/message/114835#114868 and again later:
https://externals.io/message/115037#115156
You can write your own concat_literal() function with the current
implementation:
function concat_literal(string $a, string $b): string {
if( ! is_literal($a) || ! is_literal($b) ) {
throw new TypeError;
}
return $a . $b;
}
This does everything a native version would, and can be used in all the
same places.
What it won't do, is tell you when you've forgotten to use it, and used
the normal string concatenation operator - but nor would a built-in
implementation.
Whether "$foo . $bar" is always non-literal, or non-literal only if one
of its operands is, you're going to get an error about a non-literal
string somewhere else in the program, and have to trace back to find
where the "bad" concatenation happened.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
