Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Getting Past C

blog.ntpsec.org

Post reply on HN
Print view View original

381–390 of 504 posts

Re: Getting Past C

#381

Post by pjmlp »

Sanddancer wrote: post #321
dreta wrote: post #27

Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? I do agree that C has issues (though in my opinion neighter Rust nor Go address almost any of them) i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up w…

Compiler vendors have been resistant towards putting in such features. Bounds checking slows things down, and the performance race is very much a thing in C compiler implementations -- a compiler that can deliver a few percentage points better code can be a big win to teams working on compute heavy problems. C11 has Annex K which has a lot of safety features, like memory safe arrays. Unfortunately, none of the vendor…

Annex K was required in C99 and made optional in C11, it tells everything on how C vendors see safety.

Also it is actually a joke, since it still separates the pointers and length in two separate variables, instead of using some kind of struct.

The only thing it does is have functions with better semantics on the terminating nulls.

Re: Getting Past C

#382

Post by chungy »

asdaksdhksajd wrote: post #65
asdaksdhksajd wrote: post #43

why does it take 62KLOC of C to distribute time? thats more code than the whole plan9 kernel.

doom was 52KLOC of C.

Less than that even:

  all            37641 (100.00%) in 135 files
  c              37311 (99.12%) in 66 files
  asm              232 (0.62%) in 1 files
  makefile          98 (0.26%) in 2 files

Re: Getting Past C

#383

Post by pjmlp »

nurettin wrote: post #331

Why does 90% of this huge comments section revolve around Rust? Haven't we had enough of the same already? Yes, we know it provides memory safety guarantees. Yes we know you hate everything written in C with great passion. This has been made apparent and banged on our heads for the past several dog-years. Did anyone bother to look at the sheer amount of refactoring the author & team did? Did anyone realize how diffic…

Because before C got widespread beyond UNIX, we had lots of options that are now gone, so the millennials only know Rust as having those features.

Of course we also can talk about D, Go, Swift, .NET Native, Haskell, OCaml as possible modern languages to use instead of C.

Hint, many uses of C actually only care about AOT compilation to native code, and never have spent even 1 second measuring performance.

Re: Getting Past C

#384

Post by arunmu »

Manishearth wrote: post #376
arunmu wrote: post #367

I do not contest on the opinion that Rust is a good language, but it slightly hurts me when people club C and C++ together. One can easily write correct by construction code using modern C++. Use of meta-programs allows you to create typesafe constructs. It provides you with zero cost abstractions to specify ownership of resources and ..... One has to just strive to not use the C baggage that comes with it.

C++ is much better, but still not safe. Null still exists. Moves are runtime moves, so you can still attempt to access the value at compile time. Iterator invalidation is still an issue. Of course, C++ might be "safe enough" for your use cases.

> Moves are runtime moves, so you can still attempt to access the value at compile time.

What do you mean by that ? Are you saying the standard decided to make it non-destructive moves ? Then yes, it is a possible scenario for error but also a performance advantage in some cases.

Re: Getting Past C

#385

Post by [deleted] »

Manishearth wrote: post #376
arunmu wrote: post #367

I do not contest on the opinion that Rust is a good language, but it slightly hurts me when people club C and C++ together. One can easily write correct by construction code using modern C++. Use of meta-programs allows you to create typesafe constructs. It provides you with zero cost abstractions to specify ownership of resources and ..... One has to just strive to not use the C baggage that comes with it.

C++ is much better, but still not safe. Null still exists. Moves are runtime moves, so you can still attempt to access the value at compile time. Iterator invalidation is still an issue. Of course, C++ might be "safe enough" for your use cases.

[deleted]

Re: Getting Past C

#386

Post by [deleted] »

Manishearth wrote: post #376
arunmu wrote: post #367

I do not contest on the opinion that Rust is a good language, but it slightly hurts me when people club C and C++ together. One can easily write correct by construction code using modern C++. Use of meta-programs allows you to create typesafe constructs. It provides you with zero cost abstractions to specify ownership of resources and ..... One has to just strive to not use the C baggage that comes with it.

C++ is much better, but still not safe. Null still exists. Moves are runtime moves, so you can still attempt to access the value at compile time. Iterator invalidation is still an issue. Of course, C++ might be "safe enough" for your use cases.

[deleted]

Re: Getting Past C

#387

Post by pjmlp »

giancarlostoro wrote: post #183

I wish more mention of D would happen. It is compatible with C and C++ libraries and features GC without sacrificing the good things of C and C++. I always loved the idea of Rust and Go but they are nowhere near C or C++ where it matters to me. D fits the bill, otherwise I just use Python. I like being able to design software in my own way as opposed to being told how to do it.

Me too, but although the community is great, lack of focus on how to go forward in memory management, runtime and deprecated packages, seems to keep hurting the language's appeal.

Re: Getting Past C

#388

Post by pjmlp »

w8rbt wrote: post #116

I would start by getting the code to compile with g++, then begin migrating the dangerous C constructs to safe C++ constructs. IMO, that would be a safe, reasonable thing to do.

How would you prevent other developers to write C style code?

Re: Getting Past C

#389

Post by josteink »

dreta wrote: post #27

Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening? I do agree that C has issues (though in my opinion neighter Rust nor Go address almost any of them) i just don't understand why are buffer overflows such a huge problem in C when the same thing is going to come up w…

> Can anybody make a strong case to me as to why are buffer overflows considered an issue in C when it takes like 10 minutes to write and test an array implementation that prevents that from ever happening?

That it's not a by-default and forced language-feature and that most developer aren't going to spend those 10 minutes when they need an array.

They'll just use the language-provided array-implementation instead. Which in C is very, very unsafe.

Re: Getting Past C

#390

Post by Manishearth »

arunmu wrote: post #384
Manishearth wrote: post #376

Earlier quoted context omitted.

C++ is much better, but still not safe. Null still exists. Moves are runtime moves, so you can still attempt to access the value at compile time. Iterator invalidation is still an issue. Of course, C++ might be "safe enough" for your use cases.

> Moves are runtime moves, so you can still attempt to access the value at compile time. What do you mean by that ? Are you saying the standard decided to make it non-destructive moves ? Then yes, it is a possible scenario for error but also a performance advantage in some cases.

> What do you mean by that ? Are you saying the standard decided to make it non-destructive moves ?

You can still access a value after it has been moved out. use-after-move is allowed by the compiler. It places (stdlib) types in an unspecified but valid state (I've seen C++ code reusing these types and assuming that the state after move is something in particular -- it's not).

Most optimizations you can do by reusing a moved value could be done automatically by the compiler (by using the same stack space since it statically knows that it's been moved out).

Linear types are a pretty well known pattern and could have been used as a part of the design of moves. This would have the additional benefit of removing explicit move constructors from 99% of all types out there. This has not been done (and can't be now).

Edit: The pretty rare optimization potential of runtime moves is pretty much negated by the fact that common things like reallocing a vector can't be made into a memcpy for most types, just because they have nontrivial move ctors which wouldn't exist in the compile-time move scenario.

Post reply on HN