Leon Timmermans

> @Leont How? I suspect the issue only occurs on debugging perls, I don't fully understand that because AFAICT that shouldn't affect the crypto code at all.

> Then pre-define XMALLOC etc. while compiling ltc -DXMALLOC=cryptx_malloc. That would be `-DXMALLOC=PerlMem_malloc -DXFREE=PerlMem_free` etc… But I don't think that's what's going on here.

> Please write down how it can be reproduced :) If using perlbrew, compile a perl with «perl install perl-5.38.0 --debug --thread», and install the distribution on that perl.

> you've been able to reproduce the issue on a machine that you have access to? Yes, I can reliably reproduce it on my computer.

> [karel-m](https://github.com/karel-m) added the[ should be fixed in libtomcrypt ](https://github.com/DCIT/perl-CryptX/labels/should%20be%20fixed%20in%20libtomcrypt)label I can confirm I can not reproduce the issue with CryptX 0.080_006

> @Leont which CPU model does the computer have you were seeing this on? AMD Ryzen 5 3600 6-Core Processor. gcc version 14.1.1

> I'm unsure what all should be done, or if this needs to worry about input from a slow source. @Leont ? But it starts the discussion I have a...

As far as I can tell, it's entirely legal (but unlikely) that one needs more than two reads to complete a codepoint. This change has the potential to break working...

> There is a problem with stop-at-partial handling though, any incomplete characters at end of file are discarded rather than decoded with the fallback: Yeah that's part of the "we...

> Why not merge this as an experiment since it is early in the development cycle? I really think that's a bad idea, because I believe it's wrong in a...