Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #61519 > unrolled thread

"Death To C"

Back to article view | Back to comp.lang.c

Contents

  "Death To C" Lynn McGuire <lmc@winsim.com> - 2015-05-04 14:41 -0500
    Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:16 +0200
      Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-04 13:26 -0700
        Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:51 +0200
        Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-04 22:02 +0100
          Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-05 00:06 +0200
    Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-04 13:22 -0700
      Re: "Death To C" Melzzzzz <mel@zzzzz.com> - 2015-05-04 22:41 +0200
        Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-04 20:25 -0500
          Bounds checking in C (Was: "Death To C") gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-05 02:15 +0000
            Re: Bounds checking in C (Was: "Death To C") BGB <cr88192@hotmail.com> - 2015-05-06 10:23 -0500
          Re: "Death To C" Les Cargill <lcargill99@comcast.com> - 2015-05-04 21:36 -0500
            Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:01 -0500
              Re: "Death To C" Les Cargill <lcargill99@comcast.com> - 2015-05-05 12:23 -0500
            Re: "Death To C" CHIN Dihedral <dihedral88888@gmail.com> - 2015-05-05 03:06 -0700
          Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 17:43 +1200
            Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:00 -0500
              Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 01:13 -0500
                Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 19:15 +1200
                  Re: "Death To C" Robert Wessel <robertwessel2@yahoo.com> - 2015-05-05 02:41 -0500
                    Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 20:12 +1200
          Re: "Death To C" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-05-05 06:48 +0000
          Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-05 10:57 +0100
            Re: "Death To C" asetofsymbols@gmail.com - 2015-05-05 16:53 -0700
            Re: "Death To C" Nobody <nobody@nowhere.invalid> - 2015-05-06 08:10 +0100
              Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 09:53 +0100
                Re: "Death To C" Richard Heathfield <rjh@cpax.org.uk> - 2015-05-06 13:49 +0100
                  Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 14:29 +0100
                  Re: "Death To C" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-05-06 09:43 -0700
                    Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-06 18:24 +0100
            Re: "Death To C" asetofsymbols@gmail.com - 2015-05-08 00:44 -0700
              Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-08 13:49 +0100
      Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-04 22:15 +0100
        Re: "Death To C" BGB <cr88192@hotmail.com> - 2015-05-08 09:09 -0500
      Re: "Death To C" Stephen Sprunk <stephen@sprunk.org> - 2015-05-04 16:18 -0500
      Re: "Death To C" Ian Collins <ian-news@hotmail.com> - 2015-05-05 12:49 +1200
    Re: "Death To C" raltbos@xs4all.nl (Richard Bos) - 2015-05-08 21:52 +0000
    Re: "Death To C" Merikissa <merikissa@no.spam.net> - 2015-05-10 04:04 +0300
    Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-13 08:11 -0700
      Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-13 10:00 -0700
        Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-13 18:20 +0100
          Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-14 10:47 -0700
            Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-14 11:09 -0700
            Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-15 19:21 +0100
              Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-16 09:10 -0700
                Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-16 20:45 +0100
                  Re: "Death To C" David Kleinecke <dkleinecke@gmail.com> - 2015-05-17 09:38 -0700
          Re: "Death To C" raltbos@xs4all.nl (Richard Bos) - 2015-05-17 10:47 +0000
            Re: "Death To C" Bartc <bc@freeuk.com> - 2015-05-17 12:20 +0100
        Re: "Death To C" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-05-13 10:24 -0700
          Re: "Death To C" David Brown <david.brown@hesbynett.no> - 2015-05-13 22:01 +0200
      Re: "Death To C" Nobody <nobody@nowhere.invalid> - 2015-05-14 07:48 +0100

Page 1 of 3  [1] 2 3  Next page →

#61519 — "Death To C"

"Death To C"
    http://techcrunch.com/2015/05/02/and-c-plus-plus-too/

"Ladies and gentlemen, the C programming language. It’s a classic. It is sleek, and spartan, and elegant. (Especially compared to its 
sequel, that bloated mess C++, which shares all the faults I’m about to describe.) It is blindingly, quicksilver fast, because it’s 
about as close to the bone of the machine as you can get. It is time-tested and ubiquitous. And it is terrifyingly dangerous."

So what else is new?

Lynn

[toc] | [next] | [standalone]

#61523

On Mon, 04 May 2015 14:41:44 -0500
Lynn McGuire <lmc@winsim.com> wrote:

> "Death To C"
>     http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
> 
> "Ladies and gentlemen, the C programming language. It’s a classic. It
> is sleek, and spartan, and elegant. (Especially compared to its
> sequel, that bloated mess C++, which shares all the faults I’m about
> to describe.) It is blindingly, quicksilver fast, because it’s about
> as close to the bone of the machine as you can get. It is time-tested
> and ubiquitous. And it is terrifyingly dangerous."
> 
> So what else is new?
> 
> Lynn
"
…Which is why I’m so interested in Rust.
"

Please compare this elegant C program:
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=gcc&id=1
with this ugly mess, that Rust is:
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=rust&id=1

[toc] | [prev] | [next] | [standalone]

#61526

On Monday, May 4, 2015 at 9:16:43 PM UTC+1, Melzzzzz wrote:
> On Mon, 04 May 2015 14:41:44 -0500
> Lynn McGuire <lmc@winsim.com> wrote:
> 
> > "Death To C"
> >     http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
> > 
> > "Ladies and gentlemen, the C programming language. It's a classic. It
> > is sleek, and spartan, and elegant. (Especially compared to its
> > sequel, that bloated mess C++, which shares all the faults I'm about
> > to describe.) It is blindingly, quicksilver fast, because it's about
> > as close to the bone of the machine as you can get. It is time-tested
> > and ubiquitous. And it is terrifyingly dangerous."
> > 
> > So what else is new?
> > 
> > Lynn
> "
> ...Which is why I'm so interested in Rust.
> "
> 
> Please compare this elegant C program:
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=gcc&id=1
> with this ugly mess, that Rust is:
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=rust&id=1
>
This sort of stuff

/// Pop a mutable reference off the head of a slice, mutating the slice to no

/// longer contain the mutable reference.

fn shift_mut_ref<'a, T>(r: &mut &'a mut [T]) -> Option<&'a mut T> {

    if r.len() == 0 { return None }

    let tmp = std::mem::replace(r, &mut []);

    let (h, t) = tmp.split_at_mut(1);

    *r = t;

    Some(&mut h[0])

}

is unacceptable in a general purpose language.

[toc] | [prev] | [next] | [standalone]

#61529

On Mon, 4 May 2015 13:26:53 -0700 (PDT)
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Monday, May 4, 2015 at 9:16:43 PM UTC+1, Melzzzzz wrote:
> > On Mon, 04 May 2015 14:41:44 -0500
> > Lynn McGuire <lmc@winsim.com> wrote:
> > 
> > > "Death To C"
> > >     http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
> > > 
> > > "Ladies and gentlemen, the C programming language. It's a
> > > classic. It is sleek, and spartan, and elegant. (Especially
> > > compared to its sequel, that bloated mess C++, which shares all
> > > the faults I'm about to describe.) It is blindingly, quicksilver
> > > fast, because it's about as close to the bone of the machine as
> > > you can get. It is time-tested and ubiquitous. And it is
> > > terrifyingly dangerous."
> > > 
> > > So what else is new?
> > > 
> > > Lynn
> > "
> > ...Which is why I'm so interested in Rust.
> > "
> > 
> > Please compare this elegant C program:
> > http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=gcc&id=1
> > with this ugly mess, that Rust is:
> > http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=rust&id=1
> >
> This sort of stuff
> 
> /// Pop a mutable reference off the head of a slice, mutating the
> slice to no
> 
> /// longer contain the mutable reference.
> 
> fn shift_mut_ref<'a, T>(r: &mut &'a mut [T]) -> Option<&'a mut T> {
> 
>     if r.len() == 0 { return None }
> 
>     let tmp = std::mem::replace(r, &mut []);
> 
>     let (h, t) = tmp.split_at_mut(1);
> 
>     *r = t;
> 
>     Some(&mut h[0])
> 
> }
> 
> is unacceptable in a general purpose language.

That's what I am talking about. This simple program demonstrates where
"safety" leads...

[toc] | [prev] | [next] | [standalone]

#61530

On 04/05/2015 21:26, Malcolm McLean wrote:
> On Monday, May 4, 2015 at 9:16:43 PM UTC+1, Melzzzzz wrote:

>> Please compare this elegant C program:
>> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=gcc&id=1
>> with this ugly mess, that Rust is:
>> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=rust&id=1
>>
> This sort of stuff
>
> /// Pop a mutable reference off the head of a slice, mutating the slice to no
>
> /// longer contain the mutable reference.
>
> fn shift_mut_ref<'a, T>(r: &mut &'a mut [T]) -> Option<&'a mut T> {
>
>      if r.len() == 0 { return None }
>
>      let tmp = std::mem::replace(r, &mut []);
>
>      let (h, t) = tmp.split_at_mut(1);
>
>      *r = t;
>
>      Some(&mut h[0])
>
> }
>
> is unacceptable in a general purpose language.

I completely agree. Even given that I don't know what half that stuff 
means, I don't want to have to write it no matter how good the intentions.

A good syntax shouldn't be hard to relate to the equivalent algorithm, 
and ought to be straightforward to translate to another language of 
equivalent level.

If I had to transcribe this task to an algorithm (or just try to 
understand it), I think I would go with the Ruby, Pascal or Python 
versions on that site. Even the Lisp didn't look too hard.


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#61533

On Mon, 04 May 2015 22:02:01 +0100
Bartc <bc@freeuk.com> wrote:

> On 04/05/2015 21:26, Malcolm McLean wrote:
> > On Monday, May 4, 2015 at 9:16:43 PM UTC+1, Melzzzzz wrote:
> 
> >> Please compare this elegant C program:
> >> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=gcc&id=1
> >> with this ugly mess, that Rust is:
> >> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=rust&id=1
> >>
> > This sort of stuff
> >
> > /// Pop a mutable reference off the head of a slice, mutating the
> > slice to no
> >
> > /// longer contain the mutable reference.
> >
> > fn shift_mut_ref<'a, T>(r: &mut &'a mut [T]) -> Option<&'a mut T> {
> >
> >      if r.len() == 0 { return None }
> >
> >      let tmp = std::mem::replace(r, &mut []);
> >
> >      let (h, t) = tmp.split_at_mut(1);
> >
> >      *r = t;
> >
> >      Some(&mut h[0])
> >
> > }
> >
> > is unacceptable in a general purpose language.
> 
> I completely agree. Even given that I don't know what half that stuff 
> means, I don't want to have to write it no matter how good the
> intentions.
This is because Rust doesn't allow two mutable references to same
variable, in this case, array.
You can write it "unsafe" way no problem, just initialize raw pointer 
with address of element, but this way is somehow "safe" ;)
What it does is that it splits slice of array into head and tail
replacing argument with tail and returning head. Actually you get two
references to same array anyway ...

[toc] | [prev] | [next] | [standalone]

#61525

On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
> "Death To C"
>     http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
> 
> "Ladies and gentlemen, the C programming language. It's a classic.
>  It is sleek, and spartan, and elegant. (Especially compared to its 
>  sequel, that bloated mess C++, which shares all the faults I'm about
> to describe.) It is blindingly, quicksilver fast, because it's 
> about as close to the bone of the machine as you can get. It is time-
> tested and ubiquitous. And it is terrifyingly dangerous."
> 
> So what else is new?
> 
The main problem is buffer overruns. More rarely you can also
have dangling or alisased pointers. But no-one has come up with 
a nice fix. It's easy enough to implement safe arrays in another
language, but they you lose the speed of raw writes to memory.

Rust might fix that issue without also introducing another unacceptable
problem. But then it's got a long way to go to achieve acceptance.
Thousands of language are proposed (I've done it myself, Minibasic
has found a niche as a simple, customisable Basic variant). Only
a handful are ever used for anything more than a demo project by
the language implementer and a few tools for the same language.

[toc] | [prev] | [next] | [standalone]

#61527

On Mon, 4 May 2015 13:22:02 -0700 (PDT)
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:

> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
> > "Death To C"
> >     http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
> > 
> > "Ladies and gentlemen, the C programming language. It's a classic.
> >  It is sleek, and spartan, and elegant. (Especially compared to its 
> >  sequel, that bloated mess C++, which shares all the faults I'm
> > about to describe.) It is blindingly, quicksilver fast, because
> > it's about as close to the bone of the machine as you can get. It
> > is time- tested and ubiquitous. And it is terrifyingly dangerous."
> > 
> > So what else is new?
> > 
> The main problem is buffer overruns. More rarely you can also
> have dangling or alisased pointers. But no-one has come up with 
> a nice fix.

There is no nice fix.

 It's easy enough to implement safe arrays in another
> language, but they you lose the speed of raw writes to memory.

It's easy enough to bounds check but who does it?

> 
> Rust might fix that issue without also introducing another
> unacceptable problem.

I have some experience with Rust and it is pain to program
to someone who is not used to it.
(I even submitted patch, I really like it)

 But then it's got a long way to go to achieve
> acceptance.

People like something new. Main strength of Rust is not that it is
paranoical language, but in it's pattern matching and powerful enums
that go well in combination with generic programming.


 Thousands of language are proposed (I've done it myself,
> Minibasic has found a niche as a simple, customisable Basic variant).
> Only a handful are ever used for anything more than a demo project by
> the language implementer and a few tools for the same language.

There are three languages I consider Go, Nim and Rust.
Go is stable but awfully slow (tried three implementations
llvm-go,gcc-go and plan9-go)
Nim is ok (it generates c,c++,obj-c and js) , but single man
project and python syntax.
Rust is not stable yet, but it is promising, once language spec
stabilizes.

[toc] | [prev] | [next] | [standalone]

#61538

On Mon, 4 May 2015 22:41:34 +0200, Melzzzzz <mel@zzzzz.com> wrote:

>On Mon, 4 May 2015 13:22:02 -0700 (PDT)
>Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>
>> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
>> > "Death To C"
>> >     http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
>> > 
>> > "Ladies and gentlemen, the C programming language. It's a classic.
>> >  It is sleek, and spartan, and elegant. (Especially compared to its 
>> >  sequel, that bloated mess C++, which shares all the faults I'm
>> > about to describe.) It is blindingly, quicksilver fast, because
>> > it's about as close to the bone of the machine as you can get. It
>> > is time- tested and ubiquitous. And it is terrifyingly dangerous."
>> > 
>> > So what else is new?
>> > 
>> The main problem is buffer overruns. More rarely you can also
>> have dangling or alisased pointers. But no-one has come up with 
>> a nice fix.
>
>There is no nice fix.
>
> It's easy enough to implement safe arrays in another
>> language, but they you lose the speed of raw writes to memory.
>
>It's easy enough to bounds check but who does it?


No it's really not.  C makes thorough bounds checking almost
impossible.  You *can* check named (static/automatic) and allocated
objects as a whole fairly easily (although with fairly high overhead,
usually with some sort of fat pointer scheme), doing that within
objects is nearly, if not actually, impossible while maintaining full
C semantics.

[toc] | [prev] | [next] | [standalone]

#61539 — Bounds checking in C (Was: "Death To C")

In article <gq6gkapsgtcnsrmulg96q7nvd1v919i5u6@4ax.com>,
Robert Wessel  <robertwessel2@yahoo.com> wrote:
...
>No it's really not.  C makes thorough bounds checking almost
>impossible.  You *can* check named (static/automatic) and allocated
>objects as a whole fairly easily (although with fairly high overhead,
>usually with some sort of fat pointer scheme), doing that within
>objects is nearly, if not actually, impossible while maintaining full
>C semantics.

There are two ways of doing it, both of which have been done (at least in
theory):

    1) Implement "Fat Pointers" and require that they be used exclusively.
	People can program in C, but they can't (in your new regime) use
	regular (non-fat) pointers.  Anyone who does, get fired.

    2) Implement a "safe runtime" that takes a C program and runs the
	program on that runtime.  Essentially, C becomes an interpreted
	language.  Again, anyone who doesn't conform to the new regime gets
	shot, er, I mean, fired.

-- 
Pensacola - the thinking man's drink.

[toc] | [prev] | [next] | [standalone]

#61612 — Re: Bounds checking in C (Was: "Death To C")

On 5/4/2015 9:15 PM, Kenny McCormack wrote:
> In article <gq6gkapsgtcnsrmulg96q7nvd1v919i5u6@4ax.com>,
> Robert Wessel  <robertwessel2@yahoo.com> wrote:
> ...
>> No it's really not.  C makes thorough bounds checking almost
>> impossible.  You *can* check named (static/automatic) and allocated
>> objects as a whole fairly easily (although with fairly high overhead,
>> usually with some sort of fat pointer scheme), doing that within
>> objects is nearly, if not actually, impossible while maintaining full
>> C semantics.
>
> There are two ways of doing it, both of which have been done (at least in
> theory):
>
>      1) Implement "Fat Pointers" and require that they be used exclusively.
> 	People can program in C, but they can't (in your new regime) use
> 	regular (non-fat) pointers.  Anyone who does, get fired.
>
>      2) Implement a "safe runtime" that takes a C program and runs the
> 	program on that runtime.  Essentially, C becomes an interpreted
> 	language.  Again, anyone who doesn't conform to the new regime gets
> 	shot, er, I mean, fired.
>

alternatively, one can use narrow pointers, but do operations via 
runtime functions which do safety checks via lookups, though still at a 
reasonably high performance cost (though, if done right, the lookups can 
be done in O(1), which is generally useable except in 
performance-sensitive code).

IME, the performance costs between a lookup for every operation roughly 
balances that of using fat-pointers (which need to be endlessly copied 
around in memory), but waste less memory (and fits better in cache).


for performance sensitive code though, bounds checks in general can kill 
performance (and thus make them unuseable in general). some runtimes 
though (for high level languages) are capable of optimizing away runtime 
checks (generally by proving that the access can be done without 
exceeding array bounds).


for my scripting language, I had made a distinction between 
object-reference and pointer cases, using narrow pointers for object 
references and similar, and fat pointers for explicit pointer types.

in the C FFI (and for storing into structs), they were converted to 
narrow pointers, and generally runtime lookups were used to regenerate 
the fat-pointer form when loading them back in.


I have a VM for running a C variant, but this currently only uses 
unchecked pointers (for the current use-case, performance is more 
important than safety).

[toc] | [prev] | [next] | [standalone]

#61540

Robert Wessel wrote:
> On Mon, 4 May 2015 22:41:34 +0200, Melzzzzz <mel@zzzzz.com> wrote:
>
>> On Mon, 4 May 2015 13:22:02 -0700 (PDT)
>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>
>>> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
>>>> "Death To C"
>>>>      http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
>>>>
>>>> "Ladies and gentlemen, the C programming language. It's a classic.
>>>>   It is sleek, and spartan, and elegant. (Especially compared to its
>>>>   sequel, that bloated mess C++, which shares all the faults I'm
>>>> about to describe.) It is blindingly, quicksilver fast, because
>>>> it's about as close to the bone of the machine as you can get. It
>>>> is time- tested and ubiquitous. And it is terrifyingly dangerous."
>>>>
>>>> So what else is new?
>>>>
>>> The main problem is buffer overruns. More rarely you can also
>>> have dangling or alisased pointers. But no-one has come up with
>>> a nice fix.
>>
>> There is no nice fix.
>>
>> It's easy enough to implement safe arrays in another
>>> language, but they you lose the speed of raw writes to memory.
>>
>> It's easy enough to bounds check but who does it?
>
>
> No it's really not.  C makes thorough bounds checking almost
> impossible.  You *can* check named (static/automatic) and allocated
> objects as a whole fairly easily (although with fairly high overhead,
> usually with some sort of fat pointer scheme), doing that within
> objects is nearly, if not actually, impossible while maintaining full
> C semantics.
>


For what it is worth, I have dealt with bounds checking efficiently
and with not a lot of trouble - in 'C' - for  a few decades now.

It wasn't automatic, but it wasn't hard. It cetraibnly wasn't "high
overhead".

No fat pointer scheme needed. The key is the locality of the
information needed to completely check the bounds in a succinct and
frugal manner.

1) Write out your invariants.
2) Find and bind to the data or declaration objects that specify
your invariants.
3) Enforce the invariants, one by one. Explicitly.


-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#61546

On Mon, 04 May 2015 21:36:25 -0500, Les Cargill
<lcargill99@comcast.com> wrote:

>Robert Wessel wrote:
>> On Mon, 4 May 2015 22:41:34 +0200, Melzzzzz <mel@zzzzz.com> wrote:
>>
>>> On Mon, 4 May 2015 13:22:02 -0700 (PDT)
>>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>>
>>>> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
>>>>> "Death To C"
>>>>>      http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
>>>>>
>>>>> "Ladies and gentlemen, the C programming language. It's a classic.
>>>>>   It is sleek, and spartan, and elegant. (Especially compared to its
>>>>>   sequel, that bloated mess C++, which shares all the faults I'm
>>>>> about to describe.) It is blindingly, quicksilver fast, because
>>>>> it's about as close to the bone of the machine as you can get. It
>>>>> is time- tested and ubiquitous. And it is terrifyingly dangerous."
>>>>>
>>>>> So what else is new?
>>>>>
>>>> The main problem is buffer overruns. More rarely you can also
>>>> have dangling or alisased pointers. But no-one has come up with
>>>> a nice fix.
>>>
>>> There is no nice fix.
>>>
>>> It's easy enough to implement safe arrays in another
>>>> language, but they you lose the speed of raw writes to memory.
>>>
>>> It's easy enough to bounds check but who does it?
>>
>>
>> No it's really not.  C makes thorough bounds checking almost
>> impossible.  You *can* check named (static/automatic) and allocated
>> objects as a whole fairly easily (although with fairly high overhead,
>> usually with some sort of fat pointer scheme), doing that within
>> objects is nearly, if not actually, impossible while maintaining full
>> C semantics.
>>
>
>
>For what it is worth, I have dealt with bounds checking efficiently
>and with not a lot of trouble - in 'C' - for  a few decades now.
>
>It wasn't automatic, but it wasn't hard. It cetraibnly wasn't "high
>overhead".
>
>No fat pointer scheme needed. The key is the locality of the
>information needed to completely check the bounds in a succinct and
>frugal manner.
>
>1) Write out your invariants.
>2) Find and bind to the data or declaration objects that specify
>your invariants.
>3) Enforce the invariants, one by one. Explicitly.


I'm pretty sure we're specifically talking about bounds checking
implemented by the language, not the programmer.

[toc] | [prev] | [next] | [standalone]

#61571

Robert Wessel wrote:
> On Mon, 04 May 2015 21:36:25 -0500, Les Cargill
> <lcargill99@comcast.com> wrote:
>
>> Robert Wessel wrote:
>>> On Mon, 4 May 2015 22:41:34 +0200, Melzzzzz <mel@zzzzz.com> wrote:
>>>
>>>> On Mon, 4 May 2015 13:22:02 -0700 (PDT)
>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>>>>
>>>>> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
>>>>>> "Death To C"
>>>>>>       http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
>>>>>>
>>>>>> "Ladies and gentlemen, the C programming language. It's a classic.
>>>>>>    It is sleek, and spartan, and elegant. (Especially compared to its
>>>>>>    sequel, that bloated mess C++, which shares all the faults I'm
>>>>>> about to describe.) It is blindingly, quicksilver fast, because
>>>>>> it's about as close to the bone of the machine as you can get. It
>>>>>> is time- tested and ubiquitous. And it is terrifyingly dangerous."
>>>>>>
>>>>>> So what else is new?
>>>>>>
>>>>> The main problem is buffer overruns. More rarely you can also
>>>>> have dangling or alisased pointers. But no-one has come up with
>>>>> a nice fix.
>>>>
>>>> There is no nice fix.
>>>>
>>>> It's easy enough to implement safe arrays in another
>>>>> language, but they you lose the speed of raw writes to memory.
>>>>
>>>> It's easy enough to bounds check but who does it?
>>>
>>>
>>> No it's really not.  C makes thorough bounds checking almost
>>> impossible.  You *can* check named (static/automatic) and allocated
>>> objects as a whole fairly easily (although with fairly high overhead,
>>> usually with some sort of fat pointer scheme), doing that within
>>> objects is nearly, if not actually, impossible while maintaining full
>>> C semantics.
>>>
>>
>>
>> For what it is worth, I have dealt with bounds checking efficiently
>> and with not a lot of trouble - in 'C' - for  a few decades now.
>>
>> It wasn't automatic, but it wasn't hard. It cetraibnly wasn't "high
>> overhead".
>>
>> No fat pointer scheme needed. The key is the locality of the
>> information needed to completely check the bounds in a succinct and
>> frugal manner.
>>
>> 1) Write out your invariants.
>> 2) Find and bind to the data or declaration objects that specify
>> your invariants.
>> 3) Enforce the invariants, one by one. Explicitly.
>
>
> I'm pretty sure we're specifically talking about bounds checking
> implemented by the language, not the programmer.
>


But 'C' doesn't do that. Hence the ... cognitive dissonance...

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#61558

On Tuesday, May 5, 2015 at 10:31:33 AM UTC+8, Les Cargill wrote:
> Robert Wessel wrote:
> > On Mon, 4 May 2015 22:41:34 +0200, Melzzzzz <mel@zzzzz.com> wrote:
> >
> >> On Mon, 4 May 2015 13:22:02 -0700 (PDT)
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> >>
> >>> On Monday, May 4, 2015 at 8:41:55 PM UTC+1, Lynn McGuire wrote:
> >>>> "Death To C"
> >>>>      http://techcrunch.com/2015/05/02/and-c-plus-plus-too/
> >>>>
> >>>> "Ladies and gentlemen, the C programming language. It's a classic.
> >>>>   It is sleek, and spartan, and elegant. (Especially compared to its
> >>>>   sequel, that bloated mess C++, which shares all the faults I'm
> >>>> about to describe.) It is blindingly, quicksilver fast, because
> >>>> it's about as close to the bone of the machine as you can get. It
> >>>> is time- tested and ubiquitous. And it is terrifyingly dangerous."
> >>>>
> >>>> So what else is new?
> >>>>
> >>> The main problem is buffer overruns. More rarely you can also
> >>> have dangling or alisased pointers. But no-one has come up with
> >>> a nice fix.
> >>
> >> There is no nice fix.
> >>
> >> It's easy enough to implement safe arrays in another
> >>> language, but they you lose the speed of raw writes to memory.
> >>
> >> It's easy enough to bounds check but who does it?
> >
> >
> > No it's really not.  C makes thorough bounds checking almost
> > impossible.  You *can* check named (static/automatic) and allocated
> > objects as a whole fairly easily (although with fairly high overhead,
> > usually with some sort of fat pointer scheme), doing that within
> > objects is nearly, if not actually, impossible while maintaining full
> > C semantics.
> >
> 
> 
> For what it is worth, I have dealt with bounds checking efficiently
> and with not a lot of trouble - in 'C' - for  a few decades now.
> 
> It wasn't automatic, but it wasn't hard. It cetraibnly wasn't "high
> overhead".
> 
> No fat pointer scheme needed. The key is the locality of the
> information needed to completely check the bounds in a succinct and
> frugal manner.
> 
> 1) Write out your invariants.
> 2) Find and bind to the data or declaration objects that specify
> your invariants.
> 3) Enforce the invariants, one by one. Explicitly.
> 
> 
> -- 
> Les Cargill

Well, an expert in C can pick obj C and Java up quickly. But C is designed to incorporate with assembly programs for various CPUs since the DEC-PDP main frame era.   

[toc] | [prev] | [next] | [standalone]

#61543

Robert Wessel wrote:
>
> No it's really not.  C makes thorough bounds checking almost
> impossible.  You *can* check named (static/automatic) and allocated
> objects as a whole fairly easily (although with fairly high overhead,
> usually with some sort of fat pointer scheme), doing that within
> objects is nearly, if not actually, impossible while maintaining full
> C semantics.

Well...

The one time (an avionics project) I did have to implement bounds 
checking (for allocated memory), I used the hardware MMU and gave each 
allocation it's own page.  I don't think I broke an C semantics.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#61545

On Tue, 05 May 2015 17:43:39 +1200, Ian Collins <ian-news@hotmail.com>
wrote:

>Robert Wessel wrote:
>>
>> No it's really not.  C makes thorough bounds checking almost
>> impossible.  You *can* check named (static/automatic) and allocated
>> objects as a whole fairly easily (although with fairly high overhead,
>> usually with some sort of fat pointer scheme), doing that within
>> objects is nearly, if not actually, impossible while maintaining full
>> C semantics.
>
>Well...
>
>The one time (an avionics project) I did have to implement bounds 
>checking (for allocated memory), I used the hardware MMU and gave each 
>allocation it's own page.  I don't think I broke an C semantics.


Yes, that's easy.  Much harder is:

  struct s {char s[8]; void (*fp)();} s1;
  strcpy(s1.s, "abcdefghihjk");

Preventing the above from overwriting the function pointer in the
general case, where the reference to s1.s may undergo all sorts of
mangling before actually being passed to the strcpy.

Again, it's *within* an object that C makes bounds checking very
difficult.

And allocating a guard page on either side of each allocation is only
a partial check (you can still "overflow" more than a page, and the
end of the allocated object is not well defined), overall probably a
bit less effective than sentinels, but only a bit.

[toc] | [prev] | [next] | [standalone]

#61547

On Tue, 05 May 2015 01:00:48 -0500, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Tue, 05 May 2015 17:43:39 +1200, Ian Collins <ian-news@hotmail.com>
>wrote:
>
>>Robert Wessel wrote:
>>>
>>> No it's really not.  C makes thorough bounds checking almost
>>> impossible.  You *can* check named (static/automatic) and allocated
>>> objects as a whole fairly easily (although with fairly high overhead,
>>> usually with some sort of fat pointer scheme), doing that within
>>> objects is nearly, if not actually, impossible while maintaining full
>>> C semantics.
>>
>>Well...
>>
>>The one time (an avionics project) I did have to implement bounds 
>>checking (for allocated memory), I used the hardware MMU and gave each 
>>allocation it's own page.  I don't think I broke an C semantics.
>
>
>Yes, that's easy.  Much harder is:
>
>  struct s {char s[8]; void (*fp)();} s1;
>  strcpy(s1.s, "abcdefghihjk");
>
>Preventing the above from overwriting the function pointer in the
>general case, where the reference to s1.s may undergo all sorts of
>mangling before actually being passed to the strcpy.
>
>Again, it's *within* an object that C makes bounds checking very
>difficult.
>
>And allocating a guard page on either side of each allocation is only
>a partial check (you can still "overflow" more than a page, and the
>end of the allocated object is not well defined), overall probably a
>bit less effective than sentinels, but only a bit.


A more direct example of the difficulty:

  struct s {char s[8]; char t[8]; void (*fp)();} s1;
  void *vp = &s1;
  char *cp = vp;
  cp += offsetof(s, t);
  strcpy(cp, "abcdefghihjk");

How do you prevent the strcpy from overlaying the function pointer?
Assume that these five lines are wildly separated.

[toc] | [prev] | [next] | [standalone]

#61551

Robert Wessel wrote:
> On Tue, 05 May 2015 01:00:48 -0500, Robert Wessel
> <robertwessel2@yahoo.com> wrote:
>
>> On Tue, 05 May 2015 17:43:39 +1200, Ian Collins <ian-news@hotmail.com>
>> wrote:
>>
>>> Robert Wessel wrote:
>>>>
>>>> No it's really not.  C makes thorough bounds checking almost
>>>> impossible.  You *can* check named (static/automatic) and allocated
>>>> objects as a whole fairly easily (although with fairly high overhead,
>>>> usually with some sort of fat pointer scheme), doing that within
>>>> objects is nearly, if not actually, impossible while maintaining full
>>>> C semantics.
>>>
>>> Well...
>>>
>>> The one time (an avionics project) I did have to implement bounds
>>> checking (for allocated memory), I used the hardware MMU and gave each
>>> allocation it's own page.  I don't think I broke an C semantics.
>>
>>
>> Yes, that's easy.  Much harder is:
>>
>>   struct s {char s[8]; void (*fp)();} s1;
>>   strcpy(s1.s, "abcdefghihjk");
>>
>> Preventing the above from overwriting the function pointer in the
>> general case, where the reference to s1.s may undergo all sorts of
>> mangling before actually being passed to the strcpy.
>>
>> Again, it's *within* an object that C makes bounds checking very
>> difficult.
>>
>> And allocating a guard page on either side of each allocation is only
>> a partial check (you can still "overflow" more than a page, and the
>> end of the allocated object is not well defined), overall probably a
>> bit less effective than sentinels, but only a bit.
>
>
> A more direct example of the difficulty:
>
>    struct s {char s[8]; char t[8]; void (*fp)();} s1;
>    void *vp = &s1;
>    char *cp = vp;
>    cp += offsetof(s, t);
>    strcpy(cp, "abcdefghihjk");
>
> How do you prevent the strcpy from overlaying the function pointer?
> Assume that these five lines are wildly separated.

You can't...

These are the sorts of examples where an idiomatic C++ solution can lead 
to much safer code, often where the only overhead is in the bounds checking.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#61554

On Tue, 05 May 2015 19:15:25 +1200, Ian Collins <ian-news@hotmail.com>
wrote:

>Robert Wessel wrote:
>> On Tue, 05 May 2015 01:00:48 -0500, Robert Wessel
>> <robertwessel2@yahoo.com> wrote:
>>
>>> On Tue, 05 May 2015 17:43:39 +1200, Ian Collins <ian-news@hotmail.com>
>>> wrote:
>>>
>>>> Robert Wessel wrote:
>>>>>
>>>>> No it's really not.  C makes thorough bounds checking almost
>>>>> impossible.  You *can* check named (static/automatic) and allocated
>>>>> objects as a whole fairly easily (although with fairly high overhead,
>>>>> usually with some sort of fat pointer scheme), doing that within
>>>>> objects is nearly, if not actually, impossible while maintaining full
>>>>> C semantics.
>>>>
>>>> Well...
>>>>
>>>> The one time (an avionics project) I did have to implement bounds
>>>> checking (for allocated memory), I used the hardware MMU and gave each
>>>> allocation it's own page.  I don't think I broke an C semantics.
>>>
>>>
>>> Yes, that's easy.  Much harder is:
>>>
>>>   struct s {char s[8]; void (*fp)();} s1;
>>>   strcpy(s1.s, "abcdefghihjk");
>>>
>>> Preventing the above from overwriting the function pointer in the
>>> general case, where the reference to s1.s may undergo all sorts of
>>> mangling before actually being passed to the strcpy.
>>>
>>> Again, it's *within* an object that C makes bounds checking very
>>> difficult.
>>>
>>> And allocating a guard page on either side of each allocation is only
>>> a partial check (you can still "overflow" more than a page, and the
>>> end of the allocated object is not well defined), overall probably a
>>> bit less effective than sentinels, but only a bit.
>>
>>
>> A more direct example of the difficulty:
>>
>>    struct s {char s[8]; char t[8]; void (*fp)();} s1;
>>    void *vp = &s1;
>>    char *cp = vp;
>>    cp += offsetof(s, t);
>>    strcpy(cp, "abcdefghihjk");
>>
>> How do you prevent the strcpy from overlaying the function pointer?
>> Assume that these five lines are wildly separated.
>
>You can't...
>
>These are the sorts of examples where an idiomatic C++ solution can lead 
>to much safer code, often where the only overhead is in the bounds checking.


I'm confused.  I came in with "C makes thorough bounds checking almost
impossible.  You *can* check named (static/automatic) and allocated
objects as a whole fairly easily (…), doing that within objects is
nearly, if not actually, impossible while maintaining full C
semantics."  And I got people disagreeing with me.

Certainly following some good coding techniques can help a great deal,
but you're relying on the programmer to do it right, and it can't be
easily enforced by the compiler.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web