8 ms·

Coincidentally, the libc malloc/free implementation in 7th Edition Unix is also about 200 lines of C: http://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/

by pm215 9y ago

Coincidentally, the libc malloc/free implementation in 7th Edition Unix is also about 200 lines of C: http://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/gen/malloc.c http://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/ge...

saurik 9y ago
...and coincidentally is also under a license (or lack thereof) that does not allow its use in other projects :(.
- pm215 9y ago
  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 http://www.tuhs.org/Archive/Caldera-license.pdf
shubhamjain 9y ago
Is it my unfamiliarity with C or the code is really terrible? It seems that coding practices that we have started to think of as common sense are anything but.
- gravypod 9y ago
  C had changed a lot over the years. It used to be much less standardized.
- deleted 9y ago
  [deleted]
- pm215 9y ago
  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).
  - hawski 9y ago
    It seems that it's not entirely the same semantics: https://www.spinellis.gr/blog/20170914/ https://www.spinellis.gr/blog/20170914/ ( https://news.ycombinator.com/item?id=15246690 https://news.ycombinator.com/item?id=15246690 )
    - pm215 9y ago
      That blog post is talking about the kernel's internal allocator, not the libc one.
- chubot 9y ago
  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.
  - fit2rule 9y ago
    Its pretty good C code. I don't share shubhamjains' point of view. Kind of refreshing, in my opinion. I'm trying to think what 'proper modern C' looks like by comparison to this, but I don't think I could personally rewrite this code, modern-C style, comfortably.
- nurettin 9y ago
  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.
- dahart 9y ago
  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 https://news.ycombinator.com/item?id=13571159
- bjourne 9y ago
  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.
  - throwaway613834 9y ago
    What exactly do you find the most problematic with this code?
    - bjourne 9y ago
      Isn't it self-evident? Blocks nested five levels, abused for-loop syntax, assignment in testing expressions...
      - throwaway613834 9y ago
        It's not evident, sorry. Despite what you might hear about having over three levels deep being a sin, five levels of nesting is perfectly fine. And that's not an abuse of for-loop syntax -- that's exactly how you're supposed to do an infinite loop. In fact, `while(1)` is the syntax that abuses loop notation, and consequently raises "conditional expression is constant" warnings. Assignment in conditional, though, I guess I can agree with you on...
- flohofwoe 9y ago
  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 ;)

by pm215 9y ago

saurik 9y ago

...and coincidentally is also under a license (or lack thereof) that does not allow its use in other projects :(.

pm215 9y ago
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 http://www.tuhs.org/Archive/Caldera-license.pdf

shubhamjain 9y ago

Is it my unfamiliarity with C or the code is really terrible? It seems that coding practices that we have started to think of as common sense are anything but.

gravypod 9y ago
C had changed a lot over the years. It used to be much less standardized.
deleted 9y ago
[deleted]
pm215 9y ago
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).
- hawski 9y ago
  It seems that it's not entirely the same semantics: https://www.spinellis.gr/blog/20170914/ https://www.spinellis.gr/blog/20170914/ ( https://news.ycombinator.com/item?id=15246690 https://news.ycombinator.com/item?id=15246690 )
  - pm215 9y ago
    That blog post is talking about the kernel's internal allocator, not the libc one.
chubot 9y ago
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.
- fit2rule 9y ago
  Its pretty good C code. I don't share shubhamjains' point of view. Kind of refreshing, in my opinion. I'm trying to think what 'proper modern C' looks like by comparison to this, but I don't think I could personally rewrite this code, modern-C style, comfortably.
nurettin 9y ago
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.
dahart 9y ago
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 https://news.ycombinator.com/item?id=13571159
bjourne 9y ago
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.
- throwaway613834 9y ago
  What exactly do you find the most problematic with this code?
  - bjourne 9y ago
    Isn't it self-evident? Blocks nested five levels, abused for-loop syntax, assignment in testing expressions...
    - throwaway613834 9y ago
      It's not evident, sorry. Despite what you might hear about having over three levels deep being a sin, five levels of nesting is perfectly fine. And that's not an abuse of for-loop syntax -- that's exactly how you're supposed to do an infinite loop. In fact, `while(1)` is the syntax that abuses loop notation, and consequently raises "conditional expression is constant" warnings. Assignment in conditional, though, I guess I can agree with you on...
flohofwoe 9y ago
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 ;)