Working with a product today (not mentioning names), I discovered the output from one of it's provided 'helpers' was not as documented, with additional backslashes appearing in the output where none occured in the input. A fair assumption then that this program was attempting to escape the values.

Diving into the code I discovered a likely clause which first struck me as being.

  1. Rather queer expression of logic
  2. Broken - since the regex was not escaping things correctly
I interpret this clause as; When the condition is true , $val is enclosed in double-qoutes.

                if ($val =~ s/["\\]/\\$1/g or $val =~ m/[:\s]/) {
                    $val = qq["$val"];
                }

[download]

My biggest gripe with this fragment of code is the mutating of $val in the condition. It seems very wrong to me. As a quick fix I modified the substitution regex to what I believed was intended.  if ( $val =~ s/(["\\])/\\$1/g or ..... Excellent, my short test program is now escaping things rather than replacing double-quotes with backslashes. Let's apply these changes to the vendor code - it appears in two places so I change them both.

No luck, some of the output is now correct, but mysteriously , some is not. Uh oh. The quoting is correct but some is quoted, the quotes escaped , then quoted again. I knew that mutator was evil. 

"this was quoted because of whitespace"
"\"this was quoted because of whitespace\""

[download]

Why Why Why! - I'll tell you why , $val is a scalar stored in an array. A reference to this array is used twice, in a foreach like so 

 foreach my $val ( @{$arrayref} ) {
    # do evil mutating things to $val
 }
 foreach my $val ( @{$arrayref} ) {
    # now do it AGAIN.
 }

[download]
A quick smattering of warns confirms the bad news 
FIRST LOOP
SCALAR(0x857c5cc)
SCALAR(0x857c5d8)
SCALAR(0x857c5e4)
SCALAR(0x857c5f0)
SECOND LOOP
SCALAR(0x857c5cc)
SCALAR(0x857c5d8)
SCALAR(0x857c5e4)
SCALAR(0x857c5f0)

[download]
And that's where the story ends. I'd be intrigued to hear other peoples experiences of being ambushed by a bigger bug whilst fixing another.


I can't believe it's not psellchecked

In reply to Finding bugs that lead to bigger bugs by submersible_toaster

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.