Linux's strcmp() for the m68k has always been broken

> What blew me away is the idea that there can be a bug in something that is used literally everywhere all the time.

We've become so accustomed to computers being generally unreliable that I guess people see something weird and just reboot. We checksum, run reductant servers, and just generally tolerate and work around way more failures and weirdness than we should.

It's funny because we're theoretically an industry that could be full of maths and proofs but ask anybody outside of it and you'll get "yeah computers just don't work sometimes I guess that's how it is"

Similar issue, https://sourceware.org/bugzilla/show_bug.cgi?id=22644 , which was found by a friend of mine and took is ages to track down.

memmove was broken on 32-bit executables on systems with SSE2 whenever the move occurred over the 2GB memory boundary due to an issue with signed vs unsigned integers.

> Turns out that memcpy() didn’t handle data that was not aligned to a 4 byte boundary correctly in the 32 on 64 case. It took one of our sysadmins a very very long time to find it.

That is surprising outside of the kernel. There are a large number of programs that would fail very hard very fast with that sort of artificial restriction.

> Turns out that memcpy() didn’t handle data that was not aligned to a 4 byte boundary correctly in the 32 on 64 case. It took one of our sysadmins a very very long time to find it.

That sounds like an interesting detective story. Did they write it up anywhere?

I cross compile my side-project program from 64 to 32-bit and then I noticed, it would crash when testing after updating linux

The stacktrace said the crash came from SSE memcpy. I did not bother investigating it, since I have no users anyways.

I had an really old CPU (like i5-520m). Perhaps the code required some SSE feature, it did not have

That was libc. I also use Pascal, which has its own memcpy implementation. A while ago, they discovered it does not handle alignment correctly. (like it would adjust by 4-i when it should have adjusted by i) I thought that is what I get when using Pascal rather than a more commonly used language, but apparently nothing works

That is not the first `memcpy()` issue that I have heard. There was the reverse `memcpy()` in glibc 2.13 that broke plenty of software using `memcpy()` in places where `memmove()` should have been used.

And people got funny looks for wanting to run 32 bit workloads in their own 32 bit VMs...

> I dispute that it has "always" been broken -- the bug is to do with ordering non-ascii input data, when char is unsigned.

No. As the article notes, there's also a bug when char is signed (the subtraction may overflow, which is UB for signed char, and additionally produces the wrong result even assuming defined overflow). It's just more obvious when char is unsigned.

Subtracting two chars produces an `int`. C generally promotes all smaller types to `int` before doing arithmetic, and `int` is required to be at least 16 bits. So I think the code you linked is correct?

That old C code relies on integer promotion to avoid the overflow problems that occurred in the m68k asm.

The Linux kernel has not historically had great unit testing practices--it's mostly tested with large integration tests. This is in part because it inherits old development practices where unit testing was less popular, and partially because it's kind of hard to test a lot of Kernel code outside of specialized environments (e.g., would need to include a m68k emulator in the test environment to test this code).

The doubly-linked `list` type that's used ~everywhere in the kernel didn't have any in-repo unit tests until 2019 ( https://github.com/torvalds/linux/commit/ea2dd7c0875ed31955c... ), after kunit, a library for userspace testing of kernel code, was added.

The submitter can go back and correct this by clicking "edit". The software changes capitalization only on the initial submission, not subsequent edits.

(Overall, I actually like this feature. You WOULDN'T BELIEVE the CRAZY Headlines We'd See Otherwise!)

It’s in the title so it gets capitalized.

It's the m68k target -- to a first degree approximation, no one uses this.

I'm skeptical. Odds are any such test would use short ASCII strings and probably not uncovered the problem. Also, the most common uses cases of strcmp are comparisons with 0. Any such unit test would probably do the same, further minimizing the odds of discovery.

That code is older than the culture of comprehensive automated testing. It's hard for modern minds to believe how little automated testing existed before the xunit revolution.

Yes, it boggles the mind that you didn't. Because if you have enough time to criticize other open source maintainers, you certainly have time to write the unit tests they aren't writing, right?

That's because you lack imagination, you lack knowledge about how we've gotten to where we are, and you lack understanding about the value of keeping software portable.

There are many, many reasons for maintaining support for alternate architectures. How many problems would be baked in if we always had this attitude?

Back in the day when "all the world is an i386", people complained when told about how their code has bugs when compiled on 64 bit processors. Imagine if we had baked in all of those 32-bit-centric bugs that broke compiling on 64 bit.

People do the same thing now when told their code doesn't compile cleanly on 32 bit, on PowerPC, on ARM, on big endian, et cetera. Imagine if we now acted like "all the world is an amd64", and lots of code was simply broken on aarch64?

If you were alive and paid attention through other transitions, you'd understand how every example of programmers being "forced" to care about the correctness and portability of their code has paid dividends years later.

680x0 are a newer ISA than x86 in a way, though it was 32 bit from the start so didn't need revising when 32 bit hw appeared.

You can still buy a Coldfire (now from NXP, after Motorola and Freescale) and I suspect it would have used that strcmp() implementation. The 68k family is not completely dead.

Meanwhile I'm writing a compiler for the 6502....

It is available [1] as a core for FPGAs (possibly used in some obscure ASICs to boot), and it is very possible that those applications need fairly current support. The ColdFire processors came in up to 300MHz, and modern FPGAs could probably enable even higher speeds. There are variants with Ethernet [2], so security is probably a real concern.

I would very much like to learn how to get one 1) running on an FPGA 2) running Linux and then 3) set it up to automatically run new builds.

[1] https://silvaco.com/design-ip/embedded-processors/ [2] https://www.farnell.com/datasheets/1703092.pdf

Embedded systems