It's certainly not the style I would expect C to be written these days, but I don't think it's terrible code. It was, 40 years ago, genuine shipping real-world code. There's a related quote about this in the foreword that Dennis Ritchie wrote for the reprint of the Lions commentary: "You will find linear searches, primitive data structures, C code that wouldn't compile in 1979 let alone today, and an orientation towards a machine that's little more than a memory. But you will also see in the code an underlying structure that has lasted for a long time and has managed to accommodate vast changes in the computing environment." We're still calling malloc() and free() and realloc() today with the semantics that the Unix designers assigned them in the 1970s, even if the underlying implementations are significantly different. The bones of the design are strong; the initial implementations may have been naive but they were good enough to ship (and remember there were only a fairly small group of people writing the whole OS and userland).

What seems terrible about it?

It looks good to me, although it certainly looks old.

Everything is squished together, but presumably they were using much smaller displays back then. Imagine writing code to be displayed on half of your phone's screen.

The C style is different, because this isn't ANSI C or C99, but that doesn't affect the readability much.

I can't think of any coding practices it breaks. It's low level code, which most people don't have to write these days.

I'd say it's your unfamiliarity with C, and perhaps with history too. You're talking about a release version of malloc() in Unix, this code was run by many many people on many platforms and sat underneath nearly all software running on Unix v7. How many computer systems globally ran successfully using this version of malloc? You can maybe say something bad about it if you can find a bug in it, but "really terrible" is just wrong, it doesn't make any common sense to say that.

There's a legendary comment by @arcfide regarding coding styles that discusses how people get on their high horses about patterns and styles they don't understand. I like to re-read it now and then, and reflect on how the things we want to think are "common sense" are mostly fads that will pass. https://news.ycombinator.com/item?id=13571159

C had changed a lot over the years. It used to be much less standardized.

If the goto is ticking you off, that's because moving the loop into another function and hoping it gets inlined or placing extra flags everywhere isn't practical.

Maybe because it just looks 'unfamiliar' instead of 'terrible'? Just add syntax-coloring with your favourite color-theme, your favourite tab-width, and your favourite brace-style, and it will look fine ;)

The code is indeed terrible. This

    	for(p=allocp; ; ) {
		for(temp=0; ; ) {
			if(!testbusy(p->ptr)) {
				while(!testbusy((q=p->ptr)->ptr)) {
					ASSERT(q>p&&q<alloct);

would not pass anyone's code review today. Presumably they had to write it that way to ensure that the compiler emitted adequate code.

Nobody should try to use 7th ed code in other projects, regardless of license. At this point in time it's of historical and educational interest only (it won't even compile with a modern C compiler...)

As it happens I believe 7th ed is now under a bsd-ish license due to http://www.tuhs.org/Archive/Caldera-license.pdf