Le 18/06/2021 à 12:45, Guilliam Xavier a écrit :
IIUC, with the addition of integers, the function will return true for e.g.
`'SELECT * FROM foo LIMIT ' . (int)$limit` even if $limit doesn't come from
a "static" value (e.g. random_int() or even `$_GET['limit']`)
OK I get it.
I followed the initial discussions but I didn't read everything for a while.
Doesn't it mean that is_literal() which doesn't test anymore if
something is literal does a bit more than that ?
The original intent of being able to tell if a string is literal or not
seems to be a very good idea, but now it forked to something that is
more SQL-OtherDatabase business related: this means that PHP own std
will, in my opinion, take a role it isn't supposed to have, by
arbitrarily (don't take wrongly, all discussions I had read until now
are smart and make sense) telling people what is safe, and what is not ?
The original is_literal() function idea is nice, why not having both,
is_literal() that exposes a purely technical information in one side,
and is_secure() that is more specialized and supposes what is safe or
not considering more than simply string static state, for std provided
SQL database layers ?
In such scenario, userland libraries could use, depending on their own
need, one or both of theses functions.
I'd much like to have the is_literal() function for my own needs, I do
maintain an SQL query builder, but I don't expect it to handle int and
other types as well, I'll probably continue to handle those by myself
since I have a custom escaping API. In my use case, I'd probably not use
the is_secure() function but I would use the is_literal() one, mostly
for performance reasons (avoid to escape something that doesn't need to be).
I think that both being introduced at the same time is a good idea.
Regards,
--
pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
