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

Ask HN: A retrofitted C dialect?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Ask HN: A retrofitted C dialect?

#71

Post by anqurvanillapy »

pjc50 wrote: post #18

> So unlike a few `unsafe` in a safe Rust, I want something like a few "safe" in an ambient "unsafe" C dialect. But I'm not saying "unsafe" is good or bad, I'm saying that "don't talk about unsafe vs safe", it's C itself, you wouldn't say anything is "safe" or "unsafe" in C. Eh? The critical criterion is "does your language make it difficult to write accidental RCEs". There's huge resistance to changing language at a…

> Offer real and significant benefits.

Yeah! The criterion is just there like you said.

> Do you have an opinion on the dotnet version of generics?

I'm not familiar with dotnet languages, but I have much experience implementing generics, especially how to avoid getting the poor C++ templates. Also, I believe traits (not that of C++) and typeclasses (Rust/Haskell) are definitely needed, and it's already proven too, to pair with the generics feature.

> Ceph.

My former job was to write a distributed object storage in Go and it was heavily inspired by Ceph. But subset of the design could make much benefits for a smaller company, since the initial idea to write a new one was from the pain of doing rebalancing in Ceph... oh you want to know the solution? Manual partitioning and migration by our SRE/Ops team lol. It's unexpectedly effective.

Re: Ask HN: A retrofitted C dialect?

#72

Post by anqurvanillapy »

sim7c00 wrote: post #62

Its never a bad idea to have a better C. despite having alternatives that somewhat work, usually C is just the only logical choice in certain domains, because i think a certain freedom to express things memory wise, which ofc have a lot of pitfalls, but are needed. i'd say if you want to make such a language, build embedded or core OS code with it. things that do MMIO, DMA interactions, low level IO in kernel code or…

> Build embedded or core OS code with it. things that do MMIO, DMA interactions, low level IO in kernel code or firmware (more embedded).

I have a friend currently writing a GC in C and I was making it a project to test around my ideas (where problems with generic containers, compile-time eval and static reflection kicked in so early). But these you mentioned sound more important to me, I have more friends working on RISC-V projects, I should find some inspirations from their projects. Thanks for the mention!

Re: Ask HN: A retrofitted C dialect?

#73

Post by anqurvanillapy »

sparkie wrote: post #47

The problem with existing attempts to fix C, like Cyclone, are they're creating a new language, but what we really want is C, with improvements. The approach should not be to make a new language, but to augment C with optional new features, which can be incrementally applied to existing codebases to improve them. You should start with a plain old C compiler, and add the features you want in ways that fully preserve b…

I love your gradual approach pretty much. It sounds like gradual typing but not just the typing part.

I used to make many tools with libclang Python bindings to automate some chores of refactoring. I don't remember if one could expand the macros using it, and I was told that lexer and preprocessor are messed together in Clang. So it should be quite hard to extend the existing framework.

I would definitely go into this direction, but for now it just looks like some final boss, let me finish some early quests.

Re: Ask HN: A retrofitted C dialect?

#75

Post by sparkie »

anqurvanillapy wrote: post #73
sparkie wrote: post #47

The problem with existing attempts to fix C, like Cyclone, are they're creating a new language, but what we really want is C, with improvements. The approach should not be to make a new language, but to augment C with optional new features, which can be incrementally applied to existing codebases to improve them. You should start with a plain old C compiler, and add the features you want in ways that fully preserve b…

I love your gradual approach pretty much. It sounds like gradual typing but not just the typing part. I used to make many tools with libclang Python bindings to automate some chores of refactoring. I don't remember if one could expand the macros using it, and I was told that lexer and preprocessor are messed together in Clang. So it should be quite hard to extend the existing framework. I would definitely go into thi…

I'd recommend using goblint (https://github.com/goblint) as a starting point, rather than Clang.

Re: Ask HN: A retrofitted C dialect?

#76

Post by fithisux »

C-- can be also interesting, can work from kernel (instead of hellish C/asm) to efficient math implementations (used by a high level backend, still exploiting hardware).

Instead of a extending C, we can shrink it and bring it closer to metal.

Re: Ask HN: A retrofitted C dialect?

#77

Post by anqurvanillapy »

uecker wrote: post #74

I have plan to do just this. See N3211 and N3395 for an initial sketch. https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_lo...

Cool, and the paper mentioned in the document "Dependent Types for Low-Level Programming" [1] is such a gem.

[1]: https://people.eecs.berkeley.edu/~necula/Papers/deputy-esop0...

Re: Ask HN: A retrofitted C dialect?

#78

Post by musicale »

Macha wrote: post #28
arnsholt wrote: post #23

In 2014 John Regehr and colleagues suggested what he called Friendly C[0], in an attempt to salvage C from UB. About bit more than a year later, he concluded that the project wasn't really feasible because people couldn't agree on the details of what Friendly C should be.[1] In the second post, there's an interesting comment towards the end: > Luckily there’s an easy away forward, which is to skip the step where we t…

I think the problem with "friendly C", "safe C++" proposals is they come from a place of "I want to continue using what I know in C/C++ but get some of the safety benefits. I'm willing to trade some of the safety benefits for familiarity". The problem is the friendly C/safe C++ that people picture from that is on a spectrum. On one end you have people that really just want to keep writing C++98 or C99 and see this as…

Apologies for mentioning the same idea in multiple comments, but it seems relevant.

In my opinion, a good path forward is to add safety features to mainline C toolchains. An example is -fbounds-safety for clang/llvm

https://clang.llvm.org/docs/BoundsSafetyAdoptionGuide.html

Re: Ask HN: A retrofitted C dialect?

#79

Post by musicale »

awesome_dude wrote: post #34
arnsholt wrote: post #23

In 2014 John Regehr and colleagues suggested what he called Friendly C[0], in an attempt to salvage C from UB. About bit more than a year later, he concluded that the project wasn't really feasible because people couldn't agree on the details of what Friendly C should be.[1] In the second post, there's an interesting comment towards the end: > Luckily there’s an easy away forward, which is to skip the step where we t…

> Luckily there’s an easy away forward, which is to skip the step where we try to get consensus. This is true, the Benovolant Dictator model, versus the Rule by committee model problesm. Committees are notorius for having problems coming to a consensus, because everyone wants to pull in a different direction, often at odds with everyone else. Benevolent dictators get things done, but it's not necessarily what people…

The path forward I see is improved safety features for popular C compilers and toolchains.

Ultimately it may be necessary to convince standards committees, but it seems like adding features and flags into mainline clang/llvm (and/or gcc, visual studio, ...) paves the road toward improved memory safety for C at large.

For example, if clang supported it out of the box, I could imagine OpenBSD (or macOS or other OSes that use clang) eventually compiling all (or nearly all) of its C code, including kernel, library, and userland code, in safe mode - and maybe even making it the default. In fact we already see certain safety flags and compiler/runtime features being adopted.

Re: Ask HN: A retrofitted C dialect?

#80

Post by KsassPeuk »

AlotOfReading wrote: post #67
edwcross wrote: post #54

Earlier quoted context omitted.

Funny you mentioned TrustInSoft but not its open-source origin (which is still under development and evolving in a different direction), Frama-C. I cannot compare it to IKOS, but their usefulness depends a lot on the type of code and verification needs.

I want to like Frama-C, but I've never managed to actually use it successfully on real projects and the repeated experiences have soured me on it. Getting a recent version installed was a serious chore last time I tried, and no one else is willing to deal with ACSL to get the full value.

At some point in the past you also posted the ACSL cast badly documented. I asked you what you needed exactly, but you probably missed the message. So let me try again:

What kind of documentation would you expect in addition to ACSL by Example and the WP tutorial?

Post reply on HN