91–100 of 114 posts
Earlier quoted context omitted.
Yeah but those people are running it on some platform where it’s the only choice. And they are probably running a subset of C99. The likelihood of new features ever making it to those platforms is close to zero.
There is hardly any new C compiler that isn't C11.
Earlier quoted context omitted.
Safer in what sense? We have no idea whether this hypothetical code is in a userspace application that can exit safely at any time or a hard real time system where panicking could destroy hardware. A lot of important programs (like the Linux kernel) don't operate strictly on the exact letter of the standard's UB semantics. They do things like add compiler flags to specify certain behaviors, or assume implementation d…
I will never understand how C developers can catastrophize over Rust panics, a language that has a panicless "_try" version of every panic causing function that returns a Result instead, while simultaneously accepting the infinite growth of ever harder to avoid UB in C/C++ and telling people to never have undefined behavior in their code. If you think dealing with undefined behavior is easy and you assume that people…
What I said was that panics aren't always appropriate and the context to determine this doesn't exist at the language level.
I didn't say managing UB was easy and in fact I've argued diagnosing it is impossible directly with members of both language committees. I didn't say panics are never appropriate. They usually are appropriate. I didn't say I don't use rust because X, Y, Z. I write rust. Etc.
There is no meaningful difference between a correctness bug and a panic triggering condition with the exception that the panic forces you to acknowledge the error during development, meaning it is more likely that the correctness bug gets caught in the first place.
Earlier quoted context omitted.
There is hardly any new C compiler that isn't C11.
I’ve been out of embedded for a bit but last I checked almost nothing actually implemented all of C11?
So unless they are stuck on a pre-historic fork, they support C11 as much as clang and GCC do.
Exception for stuff like PIC, Z80,...
Which didn't even support proper C on their glory days.
There's a bit of an impedence mismatch with Contracts in C because C++ contracts exist partially to rectify the fact that is broken in C++. Let's say you have a header lib.h: inline int foo(int i) { assert(i > 0); //... } In C, this function is unspecified behavior that will probably work if the compiler is remotely sane. In C++, including this in two C++ translation units that set the NDEBUG flag differently creates…
I think the main point of pre- and post-conditions is, that the compiler can see them and prove that they match and will never be triggered. There probably will be a compiler flag for outputting all non-proved pre/postconditions, there is already -fanalyzer. I think these conditions should be part of the type signature, different to what was suggested in the otherwise good talk you cited.
In general though, the compiler can't optimize across the translation unit boundary without something like LTO. The code for the callee might have already been generated by the time the caller sees that the precondition is statically satisfied.
Earlier quoted context omitted.
There's no VLA in my example.
Your example doesn't do any bounds checks, it just lets you get the sizeof. And the reason the sizeof works is the VLA infrastructure (which is not supported by MSVC so it won't compile the code). What I want is -fbounds-safety from clang.
(and msvc is stuck on partial c11 support to this day, so imo, i don't quite think it's a fair target when comparing things to new features anyway)
Earlier quoted context omitted.
I think the main point of pre- and post-conditions is, that the compiler can see them and prove that they match and will never be triggered. There probably will be a compiler flag for outputting all non-proved pre/postconditions, there is already -fanalyzer. I think these conditions should be part of the type signature, different to what was suggested in the otherwise good talk you cited.
Adding conditions to the type signature would be an ABI breaking change in C++ and have nasty interactions with templates. In general though, the compiler can't optimize across the translation unit boundary without something like LTO. The code for the callee might have already been generated by the time the caller sees that the precondition is statically satisfied.
> In general though, the compiler can't optimize across the translation unit boundary
Which is why I would put it in the function signature, so it is available in both translation units. Making the code match the function signature is currently generally the responsibility of the caller. For example when I declare an argument of type double and write an integer in the call, the compiler will convert it to a double on the callers side. I think the safety story will be similar to a printf-call today. A dumb compiler does nothing, the smart compiler adds a warning/error, when the precondition fails.
My understanding is, that on the callee's side this case is simply undefined behaviour. Much like it is today for example, that you can't pass a NULL everywhere, it might be declared to be UB, but currently this is only documented and internal to the callee and not documented in the function signature.
PS: This does not conflict with my other comment (https://news.ycombinator.com/user?id=1718627440), that this can't be implemented as a macro that invokes UB:
callee (void * p, [...])
contract_assume (nonnull (p), "p can't be NULL!")
{
p[0] = foo; -> UB
}
Earlier quoted context omitted.
D is the result of lack of interest by the C++ committee, and I had little interest in spending literally years trying to get useful things adopted into C++. Ironically, over the years, C++ has adopted many features popularized by D. (like contracts!) C++ should adopt a few more D features, like https://www.digitalmars.com/articles/C-biggest-mistake.html , compile time expression evaluation (C++ did it wrong), forwar…
> D is the result of lack of interest by the C++ committee, and I had little interest in spending literally years trying to get useful things adopted into C++. I think you are leaving out the fact that your comment applies to the post-C++98/pre-C++11 hiatus. Once C++11 was released, the truth of the matter is that whatever steam D managed to build up, it fizzed out. I'm also not sure if it's accurate to frame the pro…
- compile time function execution
- modules
- no preprocessor
- memory safe arrays
- preprocessor replacement
- ranges
and so on.
Earlier quoted context omitted.
> So to claim that the C programmers do not want change, first you need to ignore the vast majority that do want but already dropped C... Good, we can ignore them. It's not a language for everybody, and if you're happily using C++, or Zig, or Nim, keep doing that. Developer experience is a weigted sum of many variables. For you cool syntax features may play a huge role of that, for most C programmers a simple languag…
> If it's such a great language, when will we see a useful program written in it? I think it should have been simple enough to find examples, though I suppose there might be some dependence on what you mean by "useful". For standalone stuff, some examples might be Ripgrep, ruff, uv, Alacritty, and Polars. Rust is also used internally by some major companies, such as Amazon, Dropbox, Mozilla, Microsoft, Google, Volvo,…
I should've been clearer about that, but what I mean by that is pretty much what a normal non-technical person would consider an useful piece of software - Photoshop, Figma, Excel, Chrome, Windows, Android, Blender, AutoCAD, Unreal Engine, any Office Suite...
Since this is a technical forum I think we'd both easily agree on a bunch of very technically impressive software that the average person hasn't heard of - ffmpeg, qemu, LLVM, Linux, Postgres, V8, etc.
It would be a stretch to put any of the tool on either of those lists. Given the popularity of Rust, and that it's now over 10 years old, I'd expect at least one major program that can serve as an example of "here's this very useful, complex software package, as proof that our methodology works and you can do cool things this way."
Earlier quoted context omitted.
> So to claim that the C programmers do not want change, first you need to ignore the vast majority that do want but already dropped C... Good, we can ignore them. It's not a language for everybody, and if you're happily using C++, or Zig, or Nim, keep doing that. Developer experience is a weigted sum of many variables. For you cool syntax features may play a huge role of that, for most C programmers a simple languag…
> Good, we can ignore them. Who do you think you're representing? At best you only speak for yourself. It's perfectly fine if you choose to never update any tool you use, but that's just your personal opinion. You are free to stick with older standard versions of even compiler releases, but that is no justification to prevent everyone around you to improve their developer experience. > It's not a language for everybo…
1. A lot of people use the old C standards.
2. Not a lot of people use the new ones.
3. A lot of useful software is written in C.
4. Not a lot of useful software is written in any of the other languages you've listed in this conversation, despite the fact that you can hardly call them "new" at this point.
You write software your way, I'll write it mine, and in 10 years we can check our homework. The first 10 years of Rust haven't really given us any results software-wise, but I'm sure with language design powerhouses such as yourself on the case, and just a few more pieces of syntax sugar, you can turn it around.