Check for 11, 111,... if you're getting WA even when every other case (in the comments) works!

I get an NZEC error, and it's very hard to reproduce. I'm using a fuzzer called 'zuff' and to produce an NZEC with my million line file, I have to set the ratio to something like 1 in 10 bytes being bad, whereupon I get an error from data falling outside of the utf-8 range. I could maybe fix that by telling SBCL not to use UTF-8 somehow (maybe setting it to ascii?) but this appears to be well outside the scope of the problem we are given. We are not told whether data is in ascii or UTF-8, we are not told the format of the files used for the inputs (windows style EOF maybe?).

This problem is supposed to be about palindromes. If the problem is really about figuring out what bad data they are giving us, or making a program secure against non UTF-8 inputs, or something like that, they should tell us. I can feed my program 1,000,000 lines of input, containing 65,000 bytes of random data, and still not produce an NZEC. That should be sufficient for a program that is only designed to convert numbers into palindromes.

I'm doing this exercise in Common Lisp, a high level language. People doing this challenge in C probably have an easier time with it, because in C it might not be so unusual to filter inputs for a small program at the very moment the program receives them. Of course this is probably doable in Common Lisp, but I came here to do a palindromes programing challenge to increase my (beginner's level) knowledge of CL, not to learn to build a secure web server.

If I was building a secure web server, or a database server, or writing a kernel, then yes, I would need to do the work, fuzz testing the inputs at a low level to make sure the program meets it's design criteria - security - in those cases. I don't need to write a palindromes program to a standard developers don't even apply when they are building low level utilities like the ones in GNU Coreutils. If I emailed the makers of coreutils and told them 'ls' doesn't handle characters outside the UTF-8 range properly, they would probably need some more information before they were convinced it was a bug. Like 'Ok, what particular bytes are you talking about'?. They don't build 'ls' like a secure webserver because it's not one. And by the same token, a palindromes program is not a secure webserver either. It doesn't need to be secure against arbitrarily bad data.

There are no leading zeros.

I've got AC and I don't think that the implementation is difficult. Nice C++ code needs less than 80 lines of code.

can anyone explain what problem says?