Re^3: Why shows B::Deparse __END__ as __DATA_

Donc tu veux que je l'explique en Francais??? ;)

perldata documents the difference, you'll find many discussions on the matter in the monk archives.ą

Maybe B::Concise is better suited to analyze the OP tree. ( If there is any difference, NB: B::Deparse can only analyze the OP tree!)

I just noticed you didn't append any data after __DATA__ in your examples, but then optimization may influence the OP tree.

Can't check myself while posting from Android... :)

Salutations Rślf

_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

Comment on Re^3: Why shows B::Deparse __END__ as __DATA__? Download Code

Replies are listed 'Best First'.
Re^4: Why shows B::Deparse __END__ as __DATA__? by karlgoethebier (Abbot) on Oct 11, 2014 at 12:28 UTC
"Donc tu veux que je l'explique en Francais??? ;)" Non, mercy beaucoup ;-) "...you didn't append any data after __DATA__ in your examples..." Mmh, i tried it but i didn't post the examples. Seems like it doesn't matter but perhaps i'll need to retry this... Best regards, Karl «The Crux of the Biscuit is the Apostrophe»	[reply]
Re^5: Why shows B::Deparse __END__ as __DATA__? by LanX (Saint) on Oct 11, 2014 at 14:45 UTC
so I did a little testing these examples `lanx@nc10-ubuntu:/tmp$ cat end.pl print <DATA>; __END__ end lanx@nc10-ubuntu:/tmp$ cat data.pl print <DATA>; __DATA__ data` [download] produce identical op-codes. I'm not aware of a mechanisms to access the content after `__DATA__/__END__` other than reading from the file-handle of the source (i.e. `<DATA>` ) at compile/run time. Since B::Deparse is meant to analyze single files and both stop-markers are only different in a multi-file situation you might have entered an edge-case where B::Deparse has no possibility to see any difference. I.o.W. can you produce an example where there is a real difference between `__DATA__` and `__END__` where B::Deparse actually fails? Cheers Rolf _{(addicted to the Perl Programming Language and ☆☆☆☆ :)}	[reply] [d/l] [select]