From: Chris Nighswonger
This fixes the problem! Fantastic!
It's possibly a little convoluted at the moment ... maybe someone can
improve on that.
Is there any case where the marker would not be on a line by itself?
If it's not on a line by itself, it will be deemed to *not* be a marker.
If it matches /__\S+?__\n/ and is on a line by itself, it *will* be regarded
as a marker.
There is therefore still an opening (in Inline::C, at least) to break
Inline.
Even after the alteration to sub read_DATA has been made, this Inline::C
code is still broken:
void foo() {
printf ("%d\n",
__MINGW32__
+ 7);
}
Similarly, if it's valid python to rewrite
return __version__
as
return
__version__
then Inline::Python would still be broken by the latter.
I reckon it's probably a real can of worms to try and fix that - so I'll
just leave it as is (until someone complains, anyway).
I think we would have to start checking for matches against known markers
(__C__, __Python__, etc.) as you originally suggested. Even then there would
be nothing to stop me from breaking Inline::C by defining a symbol named
__Python__ (or __CPP__, etc.) and using that symbol in my Inline::C code.
Hopefully, everyone writes their code *across* the page, not *down* the page
!!
If not perhaps we could just do such as
@{$DATA{$pkg}} = split /(?m)^(__\S+?__\n)/, $data;
and eliminate the need to remove whitespace?
In the past, Inline has removed the whitespace that precedes the marker -
and it performs a check to verify that the whitespace has been removed.
So ... we need to remove the whitespace to satisfy that check.
(Alternatively, I could rewrite the check, but I think it's safer to stick
to the original formatting rules.)
In fact, in the past, Inline has removed everything (not just whitespace)
that precedes the marker on the line. So, in the past, you should have been
able to write:
__DATA__
some arbitrary stuff __Python__
......
Inline would then remove the " some arbitrary stuff " that precedes the
__Python__ marker.
This will no longer be the case. If the marker is preceded by anything other
than whitespace, it will be regarded as not being a marker.
So .... if anyone has been preceding the marker with anything other than
whitespace, they'll find their code broken.
Surely, no-one has been doing that ?
Anyway, I'll chew things over for a day or two - wait and see if there's any
other thoughts on what ought to be done.
Then I'll upload a 0.52_01 release that contains this amendment to
Inline.pm. (I'll let the list know when that happens.)
Thanks for pursuing this, Chris, Stefan.
Cheers,
Rob
