Thanks, but can't do it that way. The whole point is that we cannot redo all of the many places where we compile strings.
| [reply] |
it is an old legacy app ... we cannot redo all of the many places where we compile strings.
I understand your point - to a degree. What I've got so far is you've got a large codebase where HTML is stitched together via "<html>$str</html>" and the like, and you've discovered that $str sometimes needs to be encoded, and you can't decide whether or not until output (for reasons you haven't explained yet, but ok).
But like you showed in the root node, you're going to have to make changes to that code base: 1. you're going to have to change all the places where variables like $str are created (my $str = str::new('<encode this later>');), and 2. you're going to have to change the output code at some places (print $html->encode;).
So what I'm guessing is that the code you don't want to change is all the code like "<html>$str</html>", probably because there is lots of code like that.
But you sometimes have code like the "bad" cases in the root node. You haven't told us how many cases in your code base there are like this, but if it's not too many, perhaps you could weed them out with a warning, like this:
Another idea might be to inspect the optree of your source code to find stringifications that haven't been optimized away:
$ perl -MO=Concise,-src test.pl | perl -ne \
'/^#\s+\d+\s*:/&&($a=$_);/(?<!ex-)stringify/&&print$a,$_'
test.pl syntax OK
# 34: my $zz; $zz = "$x $y"; # warns
1a <@> stringify[$zz:257,258] sK/TARGMY,1 ->1b
Although that feels kind of hackish, and I don't have enough experience with B::Concise to say if there are any big downsides.
I could get into the Why ... but it's a long and boring story.
Telling us the background might prompt some other ideas for other solutions :-)
| [reply]
[d/l]
[select] |