Inline-0.52_01 released to CPAN

Hi,

Inline-0.52_01 has been uploaded to CPAN.
It contains just one change from Inline-0.52.

In Inline.pm's sub read_DATA() I've changed:

   @{$DATA{$pkg}} = split /(?m)(__\S+?__\n)/, $data
to:
   @{$DATA{$pkg}} = split /(?m)^[ \t]{0,}(__\S+?__\n)/, $data;

The bug that this addresses was discovered by Chris Nighswonger in some 
Inline::Python code.
It can also affect Inline::C/Inline::CPP - but only if somewhat unorthodox 
coding styles are adopted. (Not sure what other Inline::* modules might be 
affected.)

By way of example, upto and including Inline-0.52 the following Inline::C 
script would *not* compile:

##################
use Inline C => 'DATA';

foo();

__DATA__
__C__

#define __symbol__ 42

void foo() {
  printf("%d: %s\n", __symbol__
                   , "Hello\n");
}

##################

As of Inline-0.52_01 it will work as intended.

Note that this change has the potential to break existing (albeit 
ill-advisedly constructed) code.
For example, upto and including Inline-0.52 the following inline::C script 
*would* compile (and run) fine, though it should probably have not:

##################
use Inline C => 'DATA';

foo();

__DATA__
  some arbitrary garbage !@#$%^&*()_+++ __C__

#define __symbol__ 42

void foo() {
  printf("%d: %s\n", __symbol__, "Hello\n");
}

##################

As of Inline-0.52_01 it will *not* compile. (And I think that is a step in 
the right direction.)

Finally, this is not a complete fix. Even as of Inline-0.52_01 the following 
Inline::C script will *not* compile (though it's valid C code):

##################
use Inline C => 'DATA';

foo();

__DATA__
__C__

#define __symbol__ 42

void foo() {
  printf("%d: %s\n",
          __symbol__
         , "Hello\n");
}

##################

For this particular Inline::C script, '__symbol__' is still deemed by 
0.52_01 to be a marker (as is also the case with 0.52 and earlier).

AFAIK the bug affects only those scripts that place their code under a 
__DATA__ or __END__ marker.
If you do that and you have, in your code, some symbol (such as __symbol__ 
in the above examples, that's *not* a marker) that begins and ends with a 
double underscore, then you need to ensure that whenever that symbol appears 
on a line by itself, it is not immediately followed by a newline.
If the symbol never appears on a line by itself then (as of 0.52_01) you 
have nothing to worry about.
If the symbol is never followed immediately by a newline, then you have 
nothing to worry about.
If you don't place your code under a __DATA__ or __END__ marker then you 
have nothing to worry about.
If you don't have symbols in your code that begin and end with double 
underscores, then you have nothing to worry about.

So ... the conditions under which you can be bitten by this bug are quite 
limited.

I guess we could make them even more limited ... I don't see any need to 
rush into doing that. (Last thing I want to do is create breakage on a grand 
scale.)

Thanks to Chris Nighswonger and Stefan Seifert for their assistance with 
this.

It would be good if people could check that this change doesn't break other 
Inline::* module test suites. (I've checked Inline-CPP-0.42, but no others.)

Cheers,
Rob