12 ms·

I'm highly disagree that it's impossible to write high quality code in C language for a big project (I don't like his statement: The first rule of C is don't wr

I'm highly disagree that it's impossible to write high quality code in C language for a big project (I don't like his statement: The first rule of C is don't write C if you can avoid it). I was mostly C developer (80% C, 20% C++) for 4 years in a big project (I was backend developer of ICQ Instant Messenger). It has more than 2M lines of C code. Almost all libraries was written from scratch in C language (since ICQ is very old project, many of essential stuff was written within AOL). I felt comfortable to write high level code in C. When I read Nginx source code (it's written in C), I see better code quality than 90% of proprietary commercial software which is written on nice and comfortable high level languages. Good developer is able to write high quality code in C language with minimum bugs in large scale project. Regardless of how nice and high level and convenient language, bad developer will write c....y code. You can also check my personal project which is written entirely in C. (I didn't contribute for 1.5 years to my github since I was changed countries of living, jobs etc. I hope I will return to it when my life become stable again). P.S. To be clear, I think that C++11 is great language. But unlike many C++ developers, I love pure C.

stcredzero 11y ago
I remember seeing someone's C++ code at GDC and thinking to myself, "That looks like good Smalltalk!" Everything was intention revealing. Everything was about objects "sending messages" to each other. I've also seen production Smalltalk that might as well have been FORTRAN from the 70's. (Not one instance method or variable in the whole system. Everything was indexed loops.) The people and the culture/organization of the shop counts for much more than your language. Language counts for something, but it's not where you get the most bang for your buck, and it shouldn't be your first priority!
- yarrel 11y ago
  C++ isn't C. They have....different sized standards. That said you can create message-passing systems in either - Objective-C was originally a C library and cross-compiler.
  - ronwww 11y ago
    C++ was originally implemented as a preprocessor for C. Eventually, the preprocessor was replaced by a direct compiler for C++
- krylon 11y ago
  Somebody once said that Real Programmers can write FORTRAN code in any language. ;-)
- robuon619 11y ago
  Sounds interesting, do you recall the name or topic of the talk?
dsacco 11y ago
It has more than 2M lines of C code. Almost all libraries were written from scratch. Every professional security researcher reading this just raised an eyebrow and thought to themselves, "That's a vulnerable application." In fact, your team (or a similar one at AOL) did introduce vulnerabilities[1][2]. If we assume that, as you imply, AOL really was exclusively composed of above average C developers writing high quality code, this should really just demonstrate the point for us. I'm sure your team wrote high quality C code (or at the very least, tried very hard to write high quality C code), and as someone who likes C I also dislike the meme that C should simply not be written, no exceptions. I'd probably change it to, "Don't write C unless you need extreme performance, have great engineering resources and you'll generate unmitigated financial returns such to make any reasonable business risk assessment moot." That means virtually the same thing for anyone reading it, but it sounds a lot less sexy and memorable as far as programming aphorisms go. I have never professionally audited a C project and not found a vulnerability. Most of my friends in this industry would likely say the same. I've never seen a serious audit of a "large" (100kloc or more) C project by a serious, reputable firm with no vulnerabilities reported. If you wrote 2 million lines of C code, if you wrote libraries from scratch, you have serious vulnerabilities. Otherwise, your engineering practices and resources exceed NASA's in formal verification and correctness. I believe it is theoretically possible to write 100% safe C code, for some approximation of that ideal that leaves aside the ivory tower definition ("the only safe machine is the one which is off"). But I also believe this is so expensive and resource intensive (secure coding standards, audits, attempts at formal verification and provable correctness) that it's just generally not realistic in practice. The reason I am saying all of this is not to attack you or your sense of worth as a C developer. Rather, I'd like you to consider that you simply have no idea how many vulnerabilities exist in ICQ. In fact, I found eight different security reports for ICQ, linked at the bottom. One of the more serious ones allowed arbitrary email retrieval, which I'm willing to bet was introduced because your team liked to develop in-house libraries and decided to do that for POP3. C is a language which is both very powerful and which requires constant vigilance while coding. It is a language which makes pushing a buffer overflow to production on a Friday at 3 pm very easy. I bet your team was comparatively well-versed in C vulnerabilities for the time, but the very fact that you rolled libraries from scratch tells me you already have a high probability of errors showing up. Rolling a library/framework in-house is basically the first thing security researchers look for in an audit, because the third party ones are (usually) more secure due to their exposure. When you further consider the probability of third party software you did use becoming vulnerable in the future, changing compiler optimizations introducing new vulnerabilities and the sheer size of the SEI CERT Secure Coding Standard itself, you are left with a very dangerous risk profile. We cannot expect C to be a safe language for general use if you need to have the rigor of one of the best research organizations in the world coupled with the top 0.01% of all C programmers. It just isn't feasible. [1]: http://www.coresecurity.com/content/bevy-of-new-icq-vulnerabilities-surface http://www.coresecurity.com/content/bevy-of-new-icq-vulnerab... [2]: https://www.cvedetails.com/vulnerability-list/vendor_id-123/product_id-9167/AOL-ICQ.html https://www.cvedetails.com/vulnerability-list/vendor_id-123/...
defen 11y ago
This is why we can't have these discussions...everything gets interpreted literally, and it becomes some sort of ego contest. I'll take your claim at face value, that your team wrote 2M lines of C for a commercial project, with no memory corruptions, crashes, integer overflows, etc. That's a shockingly impressive achievement, one that I think has probably never been done before. But how is that a useful or replicable result, that will work in the real world for other projects? You're basically saying that everyone just needs to be a top 0.001% C programmer. This is the "abstinence-only sex education" of programming advice. It's super simple to not get STDs or have out-of-wedlock pregnancies - just don't have sex with anyone but your spouse, and ensure they do the same. It's 100% guaranteed to work, and if you don't follow that advice you're stupid and deserve whatever bad things happen to you.
- code4life 11y ago
  > This is the "abstinence-only sex education For the record, I don't think your stupid if you have a child accidentally. However, once you do accidentally have a child, the results are often not pretty, and I will feel bad watching as you deal with the consequences of your poorly thought out decision. Regarding programming, I can't see the relationship you make at all. If you write a good program, well good job. If you write a bad program, you are probably going to write a better one next time. (Ever look back at your old code?) It takes practice to get good, and the more we work at it, the better we'll get. Just keep trying.
  - khedoros 11y ago
    I think defen's point was that if a team produces truly high-quality C code, it's similar to a couple that both abstain until marriage. Yes, it's technically possible, but it's rare, and it's not something that should be the expected outcome (that is, most C code will have some problems, and most couples will have at least a little bit of regrettable sexual history before they're married). It's as if I say: "Step 1 of writing good code: Don't make mistakes. If you make mistakes, you deserve what's coming to you!" Some mistakes are expected, and essentially inevitable; they're the default, not the exception. Blaming the programmer might seem like the right thing to do, but there's more practical benefit to improving the tools and teaching programmers how to handle errors, so that we can decrease the negative impact that bugs will have.
geocar 11y ago
> I don't like his statement: The first rule of C is don't write C if you can avoid it I wanted to interpret it as you shouldn't write code if you can avoid it. I'm certain that's not what he meant, but it sounds better.
- hyc_symas 11y ago
  Similar to - the best line of code is the one you didn't need to write. Naturally that applies to all programming languages, not just C.
gosub 11y ago
Good developer is able to write high quality code in C... the sufficently smart developer is as much elusive as the sufficently smart compiler
raverbashing 11y ago
Sorry if I think you're overstating your achievements. - Was your code unit-tested? - Did you use the 'strn' functions? (strncpy, instead of strcpy for example) - Did your code run under Valgrind? (was there valgrind at that time? I'm not sure) - Was it tested for memory leaks? - Was there input fuzzying tests? I agree that there are ways of writing great C code (like nginx, the linux and BSD kernels, etc) But from a certain point on you're just wasting developer time when you would have a better solution in Java/Python/Ruby, etc with much less developer time and much less chance of bugs and security issues.
- icedchai 11y ago
  Unit tests? In C? I worked on a system processing millions of dollars a day in real time transactions, written in C++ with lower level libraries written in C. Some of it was written in K&R pre-ANSI C. There was not one unit test. And there probably still isn't.
  - 2trill2spill 11y ago
    > Unit tests? In C? Why wouldn't you unit test in C? I do and I have found lot's of bugs as a result and maintaining code is much easier.
    - icedchai 11y ago
      I agree. But it seems to happen less than in other languages. I'd say it's not part of the culture.
  - deleted 11y ago
    [deleted]
    - icedchai 11y ago
      It is, of course, possible. It is just rarely practiced, I think. It is as necessary as it is in any other language, which means either not at all, absolutely necessary, or somewhere in between depending on your point of view... I have seen a few approaches: google test (actually a C++ framework) used to test C code, "custom" test frameworks (makefiles, test-runner shell scripts, and small main() functions that actually run tests), etc.
Namrog84 11y ago
The first rule of C is don't write C if you can avoid it). I interpreted that differently than you. I didn't think take it to use another language. But to keep c code as concise as possible and to not reinvent the wheel when a good library is available.
Namrog84 11y ago
The first rule of C is don't write C if you can avoid it). I interpreted that differently than you. I didn't think take it to use another language. But to keep c code as concise as possible and to not reinvent the wheel when a good library is available.
pjmlp 11y ago
The problem are the enterprises that don't care about the quality of the C developers they hire, with big teams, high attrition and rotation of outsourcing companies. I have seen the quite a few of those and I imagine you wouldn't enjoy to audite their code.
rdtsc 11y ago
Granted I would say nginx, and perhaps Redis are quite exceptional that way. I use them as examples of nice, clear, clean C code. A good programmer will make COBOL look clean and understandable. But on average, I could way C code requires a lot more discipline, knowledge, and experience to produce quality code.
pslam 11y ago
The only possible ways you can believe you can write issue-free large scale projects in C, which don't suffer from all the usual pitfalls of C, are: * You've never deployed one. * You've never had to maintain one. * You wrote the last line of code and handed it over to the maintenance team, who then never gave you feedback. * You have no customers. * You have done a never-before-seen formal analysis of a large scale project down to the individual source line level, and made no mistakes with the formal specification. The author is correct: use C only if you must. There are still an enormous number of reasons why you must use C, but it should be a constraint imposed on you, and not a language you actively want to start a project in.
- krylon 11y ago
  > There are still an enormous number of reasons why you must use C, but it should be a constraint imposed on you, and not a language you actively want to start a project in. It's the same as with, say, goto or #ifdef's - one has to consider the alternatives and make an informed choice. Most of the time, the alternatives are preferable, but sometimes there either aren't any alternatives, or they are even worse. Which is not to say that C can't be a whole lot of fun. I love it dearly. But I, too, tend to avoid it when I can. It's just too easy to shoot yourself in the foot.
  - Roboprog 11y ago
    It's what they paid me to do in the 90s. That was a compelling reason to use C. (of course, one employer appropriately used C as a portable assembler, and respected it as such, for the purposes of developing a cross compiler and tool emulations for an older minicomputer environment; the next was doing (batch) "business applications" and foolishly spent too little on hardware and too much wasted effort on application development) Pascal (Modula) did much the same, SAFELY, but the money wasn't put into compiler optimization :-( Interesting that the GNU compiler collection now includes a very efficient Ada compiler.
    - krylon 11y ago
      > Interesting that the GNU compiler collection now includes a very efficient Ada compiler. GNAT has existed for ... at least ten years, I think. The DOD apparently paid for the development so there would be at least one open source/free software implementation. (According to Wikipedia, development started about twenty years ago, and it was merged into GCC in 2001.)
_RPM 11y ago
I just wanted to comment to your point about loving pure C over C++ and say I feel the same way.
jmspring 11y ago
There may be individual exceptions, but the key point "write simple, understandable code" for most people and cases is the right thing to do. I like tweaking younger engineers with C eccentricities, but any commercial code tends towards being as vanilla as possible with lots of error checking and docs to be as clear as possible.
unscaled 11y ago
As a C++ programmer who delved deeply into nginx, I think that your chosen example of "high quality C code" is telling of the state of C programs. It could be one of the best specimens of C code in terms of organization, but absolutely speaking it's one of the best large code-bases I had to deal with: 1. Almost devoid of any documentation. 2. No ADTs - all struct fields are directly accessed, even though there are sometimes very complicated invariants that must be preserved (and these invariants are not documented anywhere, of course). 3. Ultra-short variable names that really describe nothing but their types (it's like Hungarian notation with only the notation part). 4. These mystery variables are all defined in the top of the function of course, making them hard to trace. Does anyone even compile Nginx with C89? 5. Configuration parsing creates a lengthy boilerplate that's really hard to track. 6. Asynchronous code is very hard to track, with a myriad of phase-specific meaning for return codes, callbacks and other stuff that makes reading Boost.ASIO code look like a walk in the park. I think it really shows the sad state of C programming. Die-hard C programmers always complain C++ is hard to read because of its template and OOP abstractions, and it sometimes really is a mess to read, but C is even harder since large programs always re-implement their own half-assed version of OOP and template-macros inside.
- danmaz74 11y ago
  > but absolutely speaking it's one of the best large code-bases I had to deal with You meant "one of the worst"?
  - paulddraper 11y ago
    Either that, or best example of the worst
llamas02 11y ago
I love C too. Better to love them hate right? Make love,not war. Think youth would agree

stcredzero 11y ago

I remember seeing someone's C++ code at GDC and thinking to myself, "That looks like good Smalltalk!" Everything was intention revealing. Everything was about objects "sending messages" to each other. I've also seen production Smalltalk that might as well have been FORTRAN from the 70's. (Not one instance method or variable in the whole system. Everything was indexed loops.) The people and the culture/organization of the shop counts for much more than your language. Language counts for something, but it's not where you get the most bang for your buck, and it shouldn't be your first priority!

yarrel 11y ago
C++ isn't C. They have....different sized standards. That said you can create message-passing systems in either - Objective-C was originally a C library and cross-compiler.
- ronwww 11y ago
  C++ was originally implemented as a preprocessor for C. Eventually, the preprocessor was replaced by a direct compiler for C++
krylon 11y ago
Somebody once said that Real Programmers can write FORTRAN code in any language. ;-)
robuon619 11y ago
Sounds interesting, do you recall the name or topic of the talk?

dsacco 11y ago

It has more than 2M lines of C code. Almost all libraries were written from scratch. Every professional security researcher reading this just raised an eyebrow and thought to themselves, "That's a vulnerable application." In fact, your team (or a similar one at AOL) did introduce vulnerabilities[1][2]. If we assume that, as you imply, AOL really was exclusively composed of above average C developers writing high quality code, this should really just demonstrate the point for us. I'm sure your team wrote high quality C code (or at the very least, tried very hard to write high quality C code), and as someone who likes C I also dislike the meme that C should simply not be written, no exceptions. I'd probably change it to, "Don't write C unless you need extreme performance, have great engineering resources and you'll generate unmitigated financial returns such to make any reasonable business risk assessment moot." That means virtually the same thing for anyone reading it, but it sounds a lot less sexy and memorable as far as programming aphorisms go. I have never professionally audited a C project and not found a vulnerability. Most of my friends in this industry would likely say the same. I've never seen a serious audit of a "large" (100kloc or more) C project by a serious, reputable firm with no vulnerabilities reported. If you wrote 2 million lines of C code, if you wrote libraries from scratch, you have serious vulnerabilities. Otherwise, your engineering practices and resources exceed NASA's in formal verification and correctness. I believe it is theoretically possible to write 100% safe C code, for some approximation of that ideal that leaves aside the ivory tower definition ("the only safe machine is the one which is off"). But I also believe this is so expensive and resource intensive (secure coding standards, audits, attempts at formal verification and provable correctness) that it's just generally not realistic in practice. The reason I am saying all of this is not to attack you or your sense of worth as a C developer. Rather, I'd like you to consider that you simply have no idea how many vulnerabilities exist in ICQ. In fact, I found eight different security reports for ICQ, linked at the bottom. One of the more serious ones allowed arbitrary email retrieval, which I'm willing to bet was introduced because your team liked to develop in-house libraries and decided to do that for POP3. C is a language which is both very powerful and which requires constant vigilance while coding. It is a language which makes pushing a buffer overflow to production on a Friday at 3 pm very easy. I bet your team was comparatively well-versed in C vulnerabilities for the time, but the very fact that you rolled libraries from scratch tells me you already have a high probability of errors showing up. Rolling a library/framework in-house is basically the first thing security researchers look for in an audit, because the third party ones are (usually) more secure due to their exposure. When you further consider the probability of third party software you did use becoming vulnerable in the future, changing compiler optimizations introducing new vulnerabilities and the sheer size of the SEI CERT Secure Coding Standard itself, you are left with a very dangerous risk profile. We cannot expect C to be a safe language for general use if you need to have the rigor of one of the best research organizations in the world coupled with the top 0.01% of all C programmers. It just isn't feasible. [1]: http://www.coresecurity.com/content/bevy-of-new-icq-vulnerabilities-surface http://www.coresecurity.com/content/bevy-of-new-icq-vulnerab... [2]: https://www.cvedetails.com/vulnerability-list/vendor_id-123/product_id-9167/AOL-ICQ.html https://www.cvedetails.com/vulnerability-list/vendor_id-123/...

defen 11y ago

This is why we can't have these discussions...everything gets interpreted literally, and it becomes some sort of ego contest. I'll take your claim at face value, that your team wrote 2M lines of C for a commercial project, with no memory corruptions, crashes, integer overflows, etc. That's a shockingly impressive achievement, one that I think has probably never been done before. But how is that a useful or replicable result, that will work in the real world for other projects? You're basically saying that everyone just needs to be a top 0.001% C programmer. This is the "abstinence-only sex education" of programming advice. It's super simple to not get STDs or have out-of-wedlock pregnancies - just don't have sex with anyone but your spouse, and ensure they do the same. It's 100% guaranteed to work, and if you don't follow that advice you're stupid and deserve whatever bad things happen to you.

code4life 11y ago
> This is the "abstinence-only sex education For the record, I don't think your stupid if you have a child accidentally. However, once you do accidentally have a child, the results are often not pretty, and I will feel bad watching as you deal with the consequences of your poorly thought out decision. Regarding programming, I can't see the relationship you make at all. If you write a good program, well good job. If you write a bad program, you are probably going to write a better one next time. (Ever look back at your old code?) It takes practice to get good, and the more we work at it, the better we'll get. Just keep trying.
- khedoros 11y ago
  I think defen's point was that if a team produces truly high-quality C code, it's similar to a couple that both abstain until marriage. Yes, it's technically possible, but it's rare, and it's not something that should be the expected outcome (that is, most C code will have some problems, and most couples will have at least a little bit of regrettable sexual history before they're married). It's as if I say: "Step 1 of writing good code: Don't make mistakes. If you make mistakes, you deserve what's coming to you!" Some mistakes are expected, and essentially inevitable; they're the default, not the exception. Blaming the programmer might seem like the right thing to do, but there's more practical benefit to improving the tools and teaching programmers how to handle errors, so that we can decrease the negative impact that bugs will have.

geocar 11y ago

> I don't like his statement: The first rule of C is don't write C if you can avoid it I wanted to interpret it as you shouldn't write code if you can avoid it. I'm certain that's not what he meant, but it sounds better.

hyc_symas 11y ago
Similar to - the best line of code is the one you didn't need to write. Naturally that applies to all programming languages, not just C.

gosub 11y ago

Good developer is able to write high quality code in C... the sufficently smart developer is as much elusive as the sufficently smart compiler

raverbashing 11y ago

Sorry if I think you're overstating your achievements. - Was your code unit-tested? - Did you use the 'strn' functions? (strncpy, instead of strcpy for example) - Did your code run under Valgrind? (was there valgrind at that time? I'm not sure) - Was it tested for memory leaks? - Was there input fuzzying tests? I agree that there are ways of writing great C code (like nginx, the linux and BSD kernels, etc) But from a certain point on you're just wasting developer time when you would have a better solution in Java/Python/Ruby, etc with much less developer time and much less chance of bugs and security issues.

icedchai 11y ago
Unit tests? In C? I worked on a system processing millions of dollars a day in real time transactions, written in C++ with lower level libraries written in C. Some of it was written in K&R pre-ANSI C. There was not one unit test. And there probably still isn't.
- 2trill2spill 11y ago
  > Unit tests? In C? Why wouldn't you unit test in C? I do and I have found lot's of bugs as a result and maintaining code is much easier.
  - icedchai 11y ago
    I agree. But it seems to happen less than in other languages. I'd say it's not part of the culture.
- deleted 11y ago
  [deleted]
  - icedchai 11y ago
    It is, of course, possible. It is just rarely practiced, I think. It is as necessary as it is in any other language, which means either not at all, absolutely necessary, or somewhere in between depending on your point of view... I have seen a few approaches: google test (actually a C++ framework) used to test C code, "custom" test frameworks (makefiles, test-runner shell scripts, and small main() functions that actually run tests), etc.

Namrog84 11y ago

The first rule of C is don't write C if you can avoid it). I interpreted that differently than you. I didn't think take it to use another language. But to keep c code as concise as possible and to not reinvent the wheel when a good library is available.

Namrog84 11y ago

pjmlp 11y ago

The problem are the enterprises that don't care about the quality of the C developers they hire, with big teams, high attrition and rotation of outsourcing companies. I have seen the quite a few of those and I imagine you wouldn't enjoy to audite their code.

rdtsc 11y ago

Granted I would say nginx, and perhaps Redis are quite exceptional that way. I use them as examples of nice, clear, clean C code. A good programmer will make COBOL look clean and understandable. But on average, I could way C code requires a lot more discipline, knowledge, and experience to produce quality code.

pslam 11y ago

The only possible ways you can believe you can write issue-free large scale projects in C, which don't suffer from all the usual pitfalls of C, are: * You've never deployed one. * You've never had to maintain one. * You wrote the last line of code and handed it over to the maintenance team, who then never gave you feedback. * You have no customers. * You have done a never-before-seen formal analysis of a large scale project down to the individual source line level, and made no mistakes with the formal specification. The author is correct: use C only if you must. There are still an enormous number of reasons why you must use C, but it should be a constraint imposed on you, and not a language you actively want to start a project in.

krylon 11y ago
> There are still an enormous number of reasons why you must use C, but it should be a constraint imposed on you, and not a language you actively want to start a project in. It's the same as with, say, goto or #ifdef's - one has to consider the alternatives and make an informed choice. Most of the time, the alternatives are preferable, but sometimes there either aren't any alternatives, or they are even worse. Which is not to say that C can't be a whole lot of fun. I love it dearly. But I, too, tend to avoid it when I can. It's just too easy to shoot yourself in the foot.
- Roboprog 11y ago
  It's what they paid me to do in the 90s. That was a compelling reason to use C. (of course, one employer appropriately used C as a portable assembler, and respected it as such, for the purposes of developing a cross compiler and tool emulations for an older minicomputer environment; the next was doing (batch) "business applications" and foolishly spent too little on hardware and too much wasted effort on application development) Pascal (Modula) did much the same, SAFELY, but the money wasn't put into compiler optimization :-( Interesting that the GNU compiler collection now includes a very efficient Ada compiler.
  - krylon 11y ago
    > Interesting that the GNU compiler collection now includes a very efficient Ada compiler. GNAT has existed for ... at least ten years, I think. The DOD apparently paid for the development so there would be at least one open source/free software implementation. (According to Wikipedia, development started about twenty years ago, and it was merged into GCC in 2001.)

_RPM 11y ago

I just wanted to comment to your point about loving pure C over C++ and say I feel the same way.

jmspring 11y ago

There may be individual exceptions, but the key point "write simple, understandable code" for most people and cases is the right thing to do. I like tweaking younger engineers with C eccentricities, but any commercial code tends towards being as vanilla as possible with lots of error checking and docs to be as clear as possible.

unscaled 11y ago

As a C++ programmer who delved deeply into nginx, I think that your chosen example of "high quality C code" is telling of the state of C programs. It could be one of the best specimens of C code in terms of organization, but absolutely speaking it's one of the best large code-bases I had to deal with: 1. Almost devoid of any documentation. 2. No ADTs - all struct fields are directly accessed, even though there are sometimes very complicated invariants that must be preserved (and these invariants are not documented anywhere, of course). 3. Ultra-short variable names that really describe nothing but their types (it's like Hungarian notation with only the notation part). 4. These mystery variables are all defined in the top of the function of course, making them hard to trace. Does anyone even compile Nginx with C89? 5. Configuration parsing creates a lengthy boilerplate that's really hard to track. 6. Asynchronous code is very hard to track, with a myriad of phase-specific meaning for return codes, callbacks and other stuff that makes reading Boost.ASIO code look like a walk in the park. I think it really shows the sad state of C programming. Die-hard C programmers always complain C++ is hard to read because of its template and OOP abstractions, and it sometimes really is a mess to read, but C is even harder since large programs always re-implement their own half-assed version of OOP and template-macros inside.

danmaz74 11y ago
> but absolutely speaking it's one of the best large code-bases I had to deal with You meant "one of the worst"?
- paulddraper 11y ago
  Either that, or best example of the worst

llamas02 11y ago

I love C too. Better to love them hate right? Make love,not war. Think youth would agree