<html><head></head><body>Maybe I don't understand. It is the default because it is the first compression type we supported and was the compression type of STEP data files (which previously was an open standard for Bible data; not having anything to do with the STEP Bible Project).<br><br>The problem would be the same if ZIP was the default and you gave the ZIP compression driver LZSS data files.<br><br>In summary, if you specify the wrong driver for the data files of your module, you will get undefined behaviour. We could probably do a better job adding sanity checks to be sure the data we retrieve from a module is likely valid values, but these checks would be at the lowest level of engine use and be called very frequently, resulting is slower results all to handle a misconfiguration, so I'm not rushing to add these checks.<br><br>The bottom line is, give the LZSS drivers LZSS data and give the Zip drivers Zip data, etc.<br><br>Happy Sunday!<br><br>Troy<br><br><div class="gmail_quote">On February 28, 2021 1:45:12 AM MST, David Haslam <dfhdfh@protonmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>Still unanswered is Bastian’s good <caret></caret>question “Why is it the default then?”</div><div><br></div><div>David</div><div><br></div><div id="protonmail_mobile_signature_block"><div>Sent from ProtonMail Mobile</div></div> <div><br></div><div><br></div>On Sun, Feb 28, 2021 at 03:06, Troy A. Griffitts <<a href="mailto:scribe@crosswire.org" class="">scribe@crosswire.org</a>> wrote:<blockquote class="protonmail_quote" type="cite"> While I agree we probably shouldn't segfault, this is a bit like<br>renaming xyz.exe to xyz.doc and trying to open it in Word.<br><br>Not that is matters, but the details are that the LZSS decompressor<br>treats the entire block as uncompressed binary (because it doesn't<br>encounter any compression block signatures, because the data is not LZSS<br>data but instead ZIP encoded data) and does nothing with any of it,<br>returning the zip compressed data as-is, resulting in binary gibberish<br>when we reference it, so when we pull offset and size values from the<br>"uncompressed" block (which really isn't uncompressed), we get<br>essentially random numbers... which causes things to crash. Not sure<br>what Word does when you give it a ".doc" file which is a binary, or<br>MySQL does when you cat /dev/random > /var/data/mysql/ibdata1, but I<br>would bet it doesn't behave very well.<br><br>I would say the solution to this is don't give the LZSS filters ZIP<br>compressed data. I can try to put some sanity checks in when I read the<br>offset, size values from the "uncompressed" data and might be able to<br>prevent a crash.<br><br>Troy<br><br><br>On 2/27/21 10:19 AM, Bastian Germann wrote:<br>> Am 27.02.21 um 17:47 schrieb refdoc@gmx.net:<br>>> Could you put a bug report into JIRA?<br>><br>> https://tracker.crosswire.org/browse/API-247<br>><br>>> As such the LZSS code is experimental and should not be relied upon.<br>>><br>><br>> Why is it the default then? (according to<br>> https://wiki.crosswire.org/DevTools:conf_Files#Required_Elements_with_defaults)<br>> _______________________________________________<br>> sword-devel mailing list: sword-devel@crosswire.org<br>> http://crosswire.org/mailman/listinfo/sword-devel<br>> Instructions to unsubscribe/change your settings at above page<br>_______________________________________________<br>sword-devel mailing list: sword-devel@crosswire.org<br>http://crosswire.org/mailman/listinfo/sword-devel<br>Instructions to unsubscribe/change your settings at above page</blockquote><div><br></div><div><br></div></blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>