Am 05.09.2014 08:31, schrieb Alexander Holler:
Am 04.09.2014 21:18, schrieb Rob Landley:

What's actually wrong with C++ at a language design level.

Short version:

OMG.

It's better than C. In almost every aspect. Stop. Nothing else. Of
course, if you want to write something like systemd in Python, Perl,
Pascal, Modula or Erlang, feel free to so. And if you want more security
bugs, feel free to still use C for string handling instead of
std::string, Or still write your sorted list for every structure (or
just don't and go the slow way, because you don't find the time to do it
right in C). And ...

You don't have to understand how templates do work to use e.g.
std::string. Other people do hard stuff for you. So don't panic.


I've brought up the critics about using C in a critical and very security sensitive piece of software in userland, so I've decided a bit more explanations might make sense.

First, as you don't seem to have noticed or you don't know or you ignore the difference, let me repeat that this thread is about a piece of SW which runs in userland. So, please, keep away with any comments from Linus where he talks about kernelspace. I'm pretty sure he knows the difference.

Now let me bring up a very small piece of code which you can find in a similiar fashion in almost every piece of software which gets in contact with strings. And not just in one place or function, but in dozens or even hundred of places (inline, not in functions) in one project.

First in C++:

void foo_bar(const std::string& foo, const std::string& bar, std::string& foobar)
{
        foobar = foo + bar;
}

For those which don't know C++, this concatenates the two strings named foo and bar and puts the result into foobar.

Now an example how you would have to do that in C:

char *foo_bar(const char *foo, const char *bar)
{
        char *foobar = malloc(strlen(foo) + strlen(bar));

        strcpy(foobar, foo);
        strcat(foobar, bar);

        return foobar;
}

Do you see the difference and spot all the problems?

First I've though about not posting the answer to see the response, but that would just have ended up with a lot of people calling me a fool and/or assuming I can't write proper C. And it bears the problem that some inexperienced people might copy and paste and use it.

So at first: THE ABOVE EXAMPLE IN C IS BROKEN.

The very first problem is that foobar is allocated with the wrong size, because it doesn't take care of the terminating null byte. A very common problem already found at uncountable places.

But there are several more problems:

- What happens if foo or bar isn't terminated with a null byte?

- What happens if malloc fails?

- Who is the owner of foo, bar and/or foobar? Does the caller still owns foo and bar afterwards? Will the caller own foobar? (That means who is repsonsible to free foo, bar and foobar if they aren't used anymore).

So now we extend the above C example:

char *foo_bar(const char *foo, const char *bar)
{
        char *foobar;

        if (!foo || !bar)
                return NULL;

        foobar = malloc(strlen(foo) + strlen(bar) + 1);

        if (!foobar)
                return NULL;

        strcpy(foobar, foo);
        strcat(foobar, bar);

        return foobar;
}

This has still some problems. First, the caller has to check if foo_bar() hasn't returned NULL. A very common bug already found in uncountable places too.

Next, there is still the unsolvable problem about what happens if foo or bar isn't terminated with a null byte (in other words they aren't C strings). So you have to check all callers up to the source of foo and bar to be sure the program doesn't crash in the possible far far away place called foo_bar().

And still no comment about ownership. That means someone who just looks at the prototype or sees a call of foo_bar() somewhere has no idea about the ownership of foo, bar and the returned foobar without a comment.

So just this very simple functionality about string handling in C already contains several still open questions and is 17 lines long which have to be reviewed very carefull (e.g. to not miss the off-by-one bug). Compare this with the 4 lines in C++ which are almost impossible to do or to use wrong.

And, again, this thread is about a piece of software which runs with process ID 1, wants to control the whole system and owns all permissions to modify the system in almost every possible way. It doesn't run as some user with restricted permissions or in chroot or something similar. Some parts might do, but for sure not all (read again the above "far far away").

And now some stats. I've just checked out systemd:

git grep -E "strcat|strncat|strcpy|strncpy|strlen" | wc -l
570

git grep -E "strcat|strncat|strcpy|strncpy|memcpy|strlen" | wc -l
850

Ok, not every of those places might be part of pid 1. And several places are trivial calls like strlen("ATTR"), but it gives an idea about how many places do exist in systemd which might contain a problem wich isn't trivial to spot.

And regardless how clever and experienced these people are which are writing this piece of software, everyone is prone to do e.g. such an off-by-one bug. Maybe he writes the piece of code after having worked 12 hours, maybe he got interrupted while writing the code and continued it a day later, maybe it's full moon or maybe his last meal wasn't like it should have been.

Whatever.

This means, every piece of code in that piece of software has to be reviewed multiple times (reviewers aren't perfect too), and, as long as the software changes, every piece which changes has to be reviewed multiple times again.

I could continue with examples for lists, sets and similiar data structures, which have to be inventent again and again and again in C, whereas in C++ people can reuse some code which is already in use by many, many people in many, many other projects.

And to come to your argument about how simple everything in C is. Just look at the macro for container_of(). I wouldn't say it's such simple that everyone understands what it does. And it's just part of the Linux kernel, that means limited documentation and many people never heard of it before, compared with stuff which can be found standard libraries.

And, again, this is not about the kernelspace, it isn't the Linux kernel where Linus has managed it to organize an army of people which do look at every line again and again (and still do sometimes miss a bug). Most software projects don't have that many resources (human or not) available as the Linux kernel. In fact it's an absolute exception.

So you just don't want to use error prone C in new and non-trivial projects (if not really necessary) which are a major problem if something fails in the code.

Doing so just means nothing has be learned from the (of corse relatively short) history of software development.

Alexander Holler

PS: Please don't try to tell me that even the above C++ example ends up in some similar code as the C code. std::string is used by even more people than which do review the Linux kernel code. Besides that it was designed and reviewed by clever people too. And, just to repeat it again, we are talking about userspace, not kernelspace.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to