List of things C can't do

But other languages can.
1. Every feature in C implemented without hacks and kludges, natively.
2. Every feature more advanced than C stdlib.
3. Built-in security checks at compile time.

>>1
c can actually do all of those things.

4.varargs implemented in safe and sane manner.

>>1-3
the c standard contains enough ambiguity that a completely compliant compiler can have any features you can think of.

>>4
Indeed, and with Clang and LLVM, it's quite easy to add in your own new features, although making sure they work well with existing language features is certainly a challenge in some ways.

Ironically, you need to be a good C++ programmer to make modifications to Clang/LLVM.

For some reason every fucker on the internet is piping in on the merits / flaws of C / C++ in the past couple weeks.  Comes and goes in cycles, just like it has for the past ten years.

C is a goddamn systems programming language.  You want to write enterprise software for crappy clients in a dead-end overtime job?  You go do that in whatever language they like these days.  But you're not escaping from C.

Take, for instance, Java.  They said it was free from buffer overruns and dangling pointers and bad aliases and the like.  Well, that's more or less true.  But you can't write the Java runtime in Java, because the runtime is supposed to do exactly the things Java's supposed to prevent like pointer arithmetic.  So the Java runtime is written in C.  Guess what?  There were buffer overruns and dangling pointers in the Java runtime which they had to patch.

The other reason people use C is because it's the lingua franca of computers these days.  (Look it up, I can wait.)  You write a library in C and you can call it from whatever fucking language you want, given a little bit of glue code.  This does NOT apply to C++... you ever see someone "import boost" in Python?  Hell no.  But things like SQLite and PCRE and a craptonne of other C libraries work in Python just fine.

Get that?  People use C for things that are either impossible or just a total pain in higher level languages.  Here is your assignment.  Complete all tasks in a language with a strict type system, run time array bounds checking, and garbage collection.  Find out just how rarely these tasks are done in anything but C.

1. Write an OS kernel.
2. Write a language runtime.
3. Write a high performance database.  (It's been done in Java, but C is usually preferred).
4. Write a web accelerator (caching reverse proxy).
5. Write drivers for some new hardware.
6. Write code for an embedded system.

Just because Linus Torvalds and Zed Shaw posted new rants about C++ this month doesn't mean that anyone gives a fuck about the two bits you have to say on the matter, it's not like we really care what Torvalds or Shaw says anyway.

P.S. No language has built-in security checks.  Such a thing does not exist.  It is equally easy to write insecure software in any language.

Not this shitty thread again

>>6
1-6 was done for some languages. See (Open)Genera for example(yes, even 3, see: Statice). However, I still write most of my low-level code in C, because most low-level lisp interfaces have a very long way to go until they achieve the portability of C. Of course, if portability isn't desired, assembly fullfils the goal as well(and it can be reasonable to use with a good macro-assembler).

>It is equally easy to write insecure software in any language.
Ada.

7. 2hv symnm unstndbl byhumn whichucn rmber nxtday

>>10
What?

>>9

Ada won't prevent you from passing unquoted text to your SQL backend, it won't protect you from that stupid "admin=true" query parameter you use for authentication, and it won't stop you from writing an FTP server with anonymous write access to the root of your filesystem.

Languages can prevent certain types of crashes, they can't make your software secure.

>>12
Ada won't prevent you from passing unquoted text to your SQL backend
Actually, it will, same as most other languages. I think PHP is the only one that doesn't do this.

>>13

You're conflating libraries with languages, and I don't think you're familiar with your SQL library.  You can pass an arbitrary string as a query, right?  If you can't, then there's something wrong with your interface.  If you can, then it's easy to make a security hole.

>>14
Conflating languages with libraries is a silly complaint when talking about de facto standard libraries, and it's equally ridiculous to pretend an SQL library that explicitly supports prepared statements and uses them throughout the documentation doesn't encourage better security practices and won't improve the quality of the average application. If we're only going to look at the most perversely horrible users instead of the average case, even very high-level languages allow for, say, the equivalent of buffer overruns.

Tuna fish.

>>15

It's just an example.  The de facto libraries for SQL in C have prepared statements, as do the de facto libraries for SQL in other languages.  Yet programmers still bypass them because the programmers "know better" (maybe they're clever?), or sometimes because the programmers do not read or do not understand the documentation.  It's not "perversely horrible", it's merely mediocre, and there are a lot of programmers who do this kind of thing on a day to day basis.  (I've maintained their code, too.)

My point stands: it is easy to write insecure software in any language.  It sounds like you're arguing against a point I didn't make.  If you think there's a reasonable language out there which makes it genuinely difficult to write insecure software, that truly protects against user stupidity, please enlighten me.

Languages are not secure or insecure.  Systems are secure or insecure.

>>17
The de facto libraries for SQL in C have prepared statements, as do the de facto libraries for SQL in other languages.  Yet programmers still bypass them because the programmers "know better" (maybe they're clever?), or sometimes because the programmers do not read or do not understand the documentation.
The only language where this sort of SQL failery is really an issue is PHP, because it doesn't have prepared statements. Everywhere else, people actually use those prepared statements.

My point stands: it is easy to write insecure software in any language.
Your point doesn't stand at all, and if that was your point, it's missing the point.
It's certainly possible to write insecure software in any language, but that doesn't mean it's equally easy in every language, or that there aren't some languages that encourage writing shit software while there are others that make it comparably much harder.

Languages are not secure or insecure.  Systems are secure or insecure.
Your first statement is bullshit, but your arguments for it were the same arguments that, if they'd been right, would have rendered the second statement wrong.

>>18
The only language where this sort of SQL failery is really an issue is PHP, because it doesn't have prepared statements.
BZZZ WRONG
http://us.php.net/pdo

>>19
pedo
Reported.

>>19
You're right, he's wrong. PHP does have prepared statements. It is the only language I know of which makes it more difficult to use them than to hand-construct queries. I suppose those languages people like to blog about so much (with the probable exception of Python) might be prone to this kind of problem also.

I doubt you've seen this problem in C. If the code you maintained is in fact C I would recommend changing careers if that's the kind programmer your employer hires.

>>19
Yes, that exists now. The default standard is still the mysql_* family of functions.

25 Name: !!uF83YEPUoxODFrr 2012-01-10 19:31