Out of bounds on some XMLs

[Mingun]

I've run compare benchmarks of quick-xml and get an error on that file:

PS D:\Projects\quick-xml\compare> cargo bench 'maybe_xml/sample_rss.xml'
   Compiling quick-xml v0.31.0 (D:\Projects\quick-xml)
   Compiling compare v0.1.0 (D:\Projects\quick-xml\compare)
    Finished bench [optimized] target(s) in 13.28s
     Running benches\bench.rs (target\release\deps\bench-1f141fad38284792.exe)
Gnuplot not found, using plotters backend
Benchmarking low-level API/maybe_xml/sample_rss.xml: Warming up for 3.0000 s
thread 'main' panicked at C:\Users\Mingun\.cargo\registry\src\index.crates.io-6f17d22bba15001f\maybe_xml-0.10.0\src\read.rs:167:83:
slice index starts at 3945 but ends at 3219
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: bench failed, to rerun pass `--bench bench`
PS D:\Projects\quick-xml\compare> 

To reproduce:

1. checkout compare-benches branch of quick-xml (Update maybe_xml in compare project to the latest version and add quick-xml borrowed to compare table tafia/quick-xml#691)
2. cd <path-to-quick-xml-checkout>/compare
3. cargo bench 'maybe_xml/sample_rss.xml'

The first offset (3945) is a start of CDATA block, the second (3219) is an end of a previous CDATA block. Here I selected a range between those offsets:
https://github.com/tafia/quick-xml/blob/222532c6718d39c023136c8fe1e28ef910bbe435/tests/documents/sample_rss.xml#L26C306-L32C29

Probably this is because scan_cdata does not take pos as other scan functions, but then strange how it parse the first CDATA, because even in that case offsets should be incorrect:
https://github.com/bluk/maybe_xml/blob/trunk/maybe_xml/src/read/scanner.rs#L299

[bluk]

Thanks for the report.

You're correct. The pos is missing from scan_cdata so it fails to take the offset into account. The first CDATA was correct because it is looking for a ]]> starting from the relative beginning of the input string which happens to be the correct end of the first CDATA. I pushed a fix to trunk.