Adrian Colyer summarizes a fascinating academic paper:

This program has a bug. When given an *already encoded* input, it encodes it again (replacing % with ‘%25’). For example, the input `https://example.com/t%20c?x=1`

results in the output `https://example.com/t%2520c?x=1`

, whereas in fact the output should be the same as the input in this case.

Let’s put our probabilistic thinking caps on and try and to debug the program. We ‘know’ that the `url`

printed on line 19 is wrong, so we can assign low probability (0.05) to this value being correct. Likewise we ‘know’ that the input `url`

on line 1 is correct, so we can assign high probability (0.95). (In probabilistic inference, it is standard not to use 0.0 or 1.0, but values close to them instead). Initially we’ll set the probability of every other program variable being set to 0.5, since we don’t know any better yet. If we can find a point in the program where the inputs are correct with relatively high probability, and the outputs are *incorrect* with relatively high probability, then that’s an interesting place!

Since `url`

on line 19 has a low probability of being correct, this suggests that `url`

on line 18, and `purl_str`

at line 12 are also likely to be faulty. PI Debugger actually assigns these probabilities of being correct 0.0441 and 0.0832 respectively. Line 18 is a simple assignment statement, so if the chances of a bug here are fairly low. Now we trace the data flow. If `purl_str`

at line 12 is likely to be faulty then `s`

at line 16 is also likely to be faulty (probability 0.1176).

I’m interested to see someone create a practical implementation someday.