Can anyone recomend a good intoduction to C...

[Werner Schiendl]

> > That is of course a point, if you need to let the program inspect you
will
> > try to keep it as simple as possible.
> > But given the same functionality, I think a C++ program will not be more
> > complex.
>
> The program will not be, the language is.  It's a hard-to-judge tradeoff.
>

As to my knowledge, the application itself is inspected for safety critical
appliances.
And you must not change anything afterwards in the software or you need to
re-inspect the software.

What use would it be to check the language?

> > ...as long as it is well designed of course, nobody forces you to use
any
> > number of features at all possible
> >
> > don't you think so?
>
> I do not: C++ *forces* "any number of features" on you -- you can't
> easily subset it and ENSURE features outside of the subset are not
> intruding.
>

Why this?

You can use templates. But you can leave them at the side with no ill
effects.
You can use multiple inheritance. But, as well, you can leave it out if you
don't really need or like it.
You can use function/method overloading. But you can as well select a
distinct name.
You can use the new streams syntax introduced with C++, and it may have
additional benefits.
But nobody hinders you using the traditional APIs read, write, and friends.

> > Think about string operations: I think about 50 % of all security issues
I
> > read about are somehow related with a (string) buffer overflow. The
string
> > family of classes does not have that kind of problem.
>
> No, but it does have other issues -- e.g.,
>     std::string oneletter('A', 1);
> does NOT do what one might expect, nor does it give any warning
> in the implementations I have at hand (oneletter becomes a string
> of 65 characters all equal to '\001', not one of 1 character
> equal to 'A' -- oops, arguments the wrong way around...!-).
>

Yes, trading characters as integral types is maybe not a very good decision
from today's view on things.
However, I guess that would not do that much bad and at least not introduce
a security problem that turns out after years the software is in use.

> The trade-off is no doubt a win for std::string here -- it
> removes many more issues than it introduces.  But it's not
> so clear overall -- considering that you can't subset, not
> really.  I think that C++ (used properly, particularly with
> STRONG reliance on GOOD libraries) is a definite net win
> over C, but I can well see somebody might disagree, most
> particularly when security-crucial applications are being
> targeted.  (If I _could_ throw a switch to subset C++,
> _ensuring_ at least warnings for a zillion potential errors
> and complexities, the picture would of course change).
>

I think security is not a problem of C++...
You can easily write C or even Python code that does introduce security
problems.

- werner