Fix copying external entity from an ext_ent_handler handler

[ppisar]

With libxml2-2.12.0 and perl-5.38.0 t/44extent.t failed:

$ perl -Iblib/{lib,arch} ./t/44extent.t
1..7
Entity: line 1: parser error : Char 0x0 out of allowed range
pseudoroot
      ^
Entity: line 1: parser error : PCDATA invalid Char value 0
pseudoroot
      ^
[...]
:8: parser error : Entity 'b' failed to parse
  <b>&b;</b>
    ^
# Looks like your test exited with 2 before it could output anything.

The cause was xmlParserInputBufferCreateMem() which does not copy a supplied buffer. A string returned by the ext_ent_handler handler. As a result, libxml2 read from a deallocated memory parsing random garbage.

This patch fixes it by copying the string with xmlParserInputBufferPush().

https://github.com/shlomif/perl-XML-LibXML/issues/81

[ppisar]

Thanks for merging it.

May I know what's the point of your next "more robust type conversion" commit? C standard says in 6.3.1.3 section:

When a value with integer type is converted to another integer type other than _Bool , if the value can be represented by the new type, it is unchanged.

This is what happens if results_len <= INT_MAX. Hence what's the point of int_results_len != results_len?

[shlomif]

Thanks for merging it.

May I know what's the point of your next "more robust type conversion" commit? C standard says in 6.3.1.3 section:

When a value with integer type is converted to another integer type other than _Bool , if the value can be represented by the new type, it is unchanged.

This is what happens if results_len <= INT_MAX. Hence what's the point of int_results_len != results_len?

"The difference between theory and practice is that in theory, there is no difference between theory and practice, while in practice, there is.". I'd rather be safe than sorry.

also: https://www.joelonsoftware.com/2008/03/17/martian-headsets/