Re: Teach myself C++.

Peter Fairbrother <zenadsl6186@xxxxxxxxx> wrote:

Richard Herring wrote:
Especially when you don't know exactly what the compiler will do.

That seems to be an objection to the quality of implementation of
current compilers, not the language itself.

The language IS the compilers.

Not really. As pointed out elsewhere in this thread, Ruby is not
necessarily a bad language (I don't know it, so I can't tell), but its
implementation is very slow.


I'd like to suggest that someone write a compiler which behaves
properly, and more importantly, repeatably - for instance, it
should be possible to compile some code more than once, and always
get the same binary.

For a start.

Why?

Because if you can't even do that, then you have NO IDEA what might be
happening with your code - and you can't even *pretend* to be doing it
securely, never mind actually be doing it securely.

You have no idea anyway, unless you inspect the assembly code. Also the
produced code depends on incredibly many factors like compiler version,
patches, flags, etc.


That way you could say that binary X is derived from source code X
- and today, in general, you can't do even that.

So what?

Well, for a start, the idea that peer-reviewed code (which
incidentally isn't a very good idea, but it's given us OpenBSD, so it
can't be all bad - or all good) can help security goes out of the
window, or at least gets taken to one remove - unless you want your
users to compile their own code? Thought not.

So the users get binaries - but can you check the binaries are from
the code? In general, you can't, so you have to trust someone -

- and remember our definition of trust; "A thing which is trusted is
a thing which can betray you".

You're just moving the problem, not removing it. Who is the authority
who says: "This code is the correct one"? If you want to trust
something, you have to build it out of things, which are beyond human
influence (e.g. the laws of physics), i.e. you need to build your
computer yourself, write a compiler for it and compile only source code
you have reviewed.

Comparing binary code is not a security measure. Use a secure
distribution of your operating system. That's the best you can do.


Of course, I'd like even more to see a (more) secure language,
perhaps a simpler subset of a C, where eg overflows of any kind
can't happen, and a process simply can't access memory which hasn't
been allocated to it without some external permissions stuff - but
that's probably a new language entirely.

And this is what most C programmers get wrong all the time. You
don't need a _subset_ of C. In fact you need more than C.

Yes - and no.

The commands should be a subset of C, or less in number than the C
command set - but the type system should do automatic checking (and
probably be entirely automatic, there's little need to specify types
these days), and buffer overflows, accesses to the wrong sort of
memory, and so on, ought to be impossible.

What are commands? I already find C very unexpressive. A lot of
problems arise from order of statements (like: first allocate, then
work, then free; like: first add, then multiply). With less "commands"
to work with, you increase that dependency even more. Imagine we would
remove the mathematical operators and limit ourselves to assignments (=,
+=, *=, etc.). This would make the code much harder to read and much
less reliable.


And of course, destructors should be automatic and ubiquitous too :)

At least C++ has solved this problem. You can solve it in C, too, with
some tricks. I have written a blog article about it [1].

[1] http://blog.ertes.de/2009/02/continuations-for-secure-code.html


This means that the "instruction set" of the language needs to be very
small, otherwise it can't be done - smaller than that of C, though
there are a couple of things I'd add to C about strings maybe.

I wouldn't. C keeps the handling of strings in the proper layer by
viewing them as what they really are: a sequence of characters. In fact
I'd say that string handling is something most other languages get
wrong. I'd just completely abandon the insecure string functions and
abstract away the memory handling. Also some more useful string
functions would be useful, including bounds-checking access to
individual characters.

I'd rather add some language constructs, for which it makes sense to be
in the language layer, like advanced control constructs (exceptions),
new first class objects (like closures) and a sophisticated type system.


Greets,
Ertugrul.


--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/

.

Relevant Pages

  • Re: GMP vs. straight C arithmetic
    ... ordinary data structures that don't impose an additonal performance ... Side-effects are another crucial part of the language. ... > Take the tree structure example I gave earlier. ... determined at compile time, is this a compile time error? ...
    (comp.programming)
  • Resolved: NOT. --WAS: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming:OO
    ... I certainly want more errors detected at compile time, ... > advocate reaching that goal through beefier type systems. ... in a procedural language, or in an object based language. ... Relativistic mechanics - solves the transaction thing, ...
    (comp.object)
  • Re: dynamic vs. static: the age-old debate
    ... necessary to compile a program, ... inseparably related to either dynamic or static typing, ... otherwise static language, and with similar effort, can write a largely ... I have the feeling you are not separating semantics and implementation; ...
    (comp.lang.misc)
  • Re: c#.net or vb.net
    ... Both C# and VB.NET compile to the _same_ IL don't they? ... developers using any particular development tool might make the body of code ... for a particular project doesn't make the language itself more "powerful," ... although that situation might make it more popular. ...
    (microsoft.public.cert.exam.mcad)
  • Re: Operator overloading in C
    ... All development of C as an independent language has ... making any changes or improvements to the standard ... The lack of a counted string data structure, ... Pointers can't be used for arg1 or arg2. ...
    (comp.std.c)
Loading