From rra@stanford.edu

INN 2.3 makes the article body of an incoming article available to an
embedded Perl filter by doing​:

  static SV *body = NULL;

[...]

  if (!body) {
  body = newSV(0);
  (void) SvUPGRADE(body, SVt_PV);
  }
  SvPVX(body) = artBody;
  SvCUR_set(body, strlen(artBody));
  SvLEN_set(body, 0);
  SvPOK_on(body);
  SvREADONLY_on(body);
  SvREFCNT_inc(body);
  hv_store(hdr, "__BODY__", 8, body, 0);

where hdr is the HV for %hdr in the interpretor's symbol table. This
method of providing a read-only window into separately allocated memory
was based on some discussion on perl-xs.

This has exposed a couple of interesting problems. For one, if you do​:

  $lines = $hdr{__BODY__} =~ tr/\n/\n/;

Perl will throw an exception saying that you're modifying a read-only
value. If, however, you do​:

  $lines = $hdr{__BODY__} =~ tr/\n//;

it will work as expected. It sounds like the logic for determining
whether the tr/// is actually going to make any changes doesn't take into
account manually repeating the list of characters.

Second, if you do something like​:

  $body = $hdr{__BODY__};
  $lines = $body =~ tr/\n/\n/;

this appears to result in a memory leak in Perl. Is something related to
the SvLEN_set(body, 0) bit causing the SV to get copied and still have a
LEN of 0, marking it as unfreeable?

--
Russ Allbery (rra@​stanford.edu) <URL​:http​://www.eyrie.org/~eagle/>

From @chipdude

The difference between tr/\n// and tr/\n/\n/ has been fixed.
Not sure about the leak.

From @chipdude

The memory leak is apparently the result of an unnecessary
SvREFCNT_inc(). closing

@chipdude - Status changed from 'open' to 'resolved'