Inline-0.52_01 released to CPAN

[s***@public.gmane.org]

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