Earlier quoted context omitted.
A snowflake RTOS without POSIX, call me amazed.
I'm happy you learned something.
Not really, still waiting for the name of such marvelous OS.
C meeting is over. C23 added:
321–330 of 363 posts
Re: C meeting is over. C23 added:
#322Earlier quoted context omitted.
Access to CPU-specific flags like the carry flag. When doing a multiple-precision addition, if the CPU carry bit is inaccessible, then it must instead be compared to the result to see if it overflowed, which takes 3-5 more instructions per limb or worse on modern superscalar processors that are serial in terms of data accesses.
Portable by definition means it cannot capture every specific detail of every architecture out there.
By definition there isn't such thing as portable Assembly.
Re: C meeting is over. C23 added:
#323Earlier quoted context omitted.
Standard practice they say, https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...
Mozilla is not a Linux distro. You have made dozens of negative (and sometimes rude) comments in this thread. I'm curious why you're spending so much time and energy being negative. If C isn't something you're interested in, why not just ignore it and move on?
C powers lots of junk where I as a user don't have a choice other than put up with security mitigations.
Being rude, yeah that is how people defend themselves when reality doesn't check.
Re: C meeting is over. C23 added:
#324Finally C catches up with Algol 60 boolean types, it only took 60 years. Maybe in another 60 it will get proper strings and arrays.
I wonder what other string could have C used 50 years ago that would have stayed usable for that long. I love that, thanks to C, plenty of old programs can still be used today. In these days of accelerated bit-rot and language "communities", and perpetual rewrite of everything over and over again, C stability and ubiquity is a safe harbor, and has been at least until now a good investment. I have no idea what you mea…
Just like JOVIAL or FORTRAN from 1950's, you get to know their size at any time, and yes bounds checking.
Re: C meeting is over. C23 added:
#325Earlier quoted context omitted.
I'm not arguing that it is not? It's funny though how many people saw value in C but not in Algol. Maybe C has something going for it?
Who, except for people too young to know better, saw value in C but not in Algol? The Bell Labs folks obviously thought enough of Algol such that C is a descendant in the family of Algol-like languages. Algol was widely used in Europe whereas in the U.S. we made do with Fortran, Cobol, and, I think to a lesser extent, PL/I, although the latter had many Algol-like features at the time. (And Fortran evolved to have man…
I have nothing against Algol. Turbo Pascal was my first language (i agree with you about Turbo C). I loved it at the time. But C is different. The same way Lisp is different. It is just one of those languages which have a very simple core idea which is also very powerful at the same time.
Lisp has the code-data duality (everything is a list) going for it and C has everything is pointer to a block of memory and that's it. That block can be a device register, data structure, array of sth. or just about anything you can imagine. This idea enables you some kind of proto-polymorphism without the verbosity and chains of higher level languages (at the cost of safety of course). That is the beauty of C and unlike Lisp it is also lot closer to the metal, which helped a lot with performance.
I think it's normal to be jaded when something objectively superior is being replaced with something simpler. But that doesn't mean the simpler thing is without merit. The world has more dimensions, the technical aspect is just one of it.
Re: C meeting is over. C23 added:
#326> In its London 2019 meeting, WG14 has found consensus to elevate false and true to proper keywords. The committee settled this over a beer, or some other substance? Because the elevation to a proper type is opportunistic at best, and against the spirit of C at worst. Next people celebrate this with the use of capslock. The futility of it all blows my mind :C
> the elevation to a proper type is opportunistic at best, and against the spirit of C at worst Can you explain what you mean by this?
So C is all about the machine, in this case about storage, memory. Other languages emphasize types, whereas C instead emphasizes values and their representation.
So a condition or comparison does not result in a boolean, it results in a value that can be stored in 1 bit. Its values therefore are 0 and 1. There is nothing to understand, except that the values are dictated by the width of the storage, as usual. The stdbool annotation is cultural, optional, but not C. C does not have boolean values. True and false are mental crutches, names that are somewhat helpful in the absence of an explicit bit type, but still very much a lie.
I think people coming from other languages are driving the future of C now. They are used to booleans as a distinct type, exclusive from other types. Yet in C any int or pointer value has a boolean interface defined on it, and the ambiguous nature of, for for example a timeout, being both a value (time remaining) and a boolean (timed out), highlights the why of C and why C is the king of embedded programming.
So at minimum there are multiple aspects of "booleans" in C that other languages specifically de-emphasize, like storage, representation and the ambiguity of values with other types. The synthesis of the newly introduced C booleans seemingly doesn't take this impedance mismatch into account. From reading it seems there is no synthesis.
Bits have been a traditionally dark corner of C, as I can't declare or index an array of bits; and bit-fields are not my cup of tea (don't use them). I think that's where improvements can be made. Specifically the introduction of a bit type would be in the spirit of C. No need to rename the values, 0 and 1 are more truthful than true and false. If true and false are needed, then a distinct boolean type (as in other languages) might make sense, as an addition, not a replacement. Just to get true/false values and conceptual isolation.
stdbool could not do that and made compromises. Cxx enshrines that compromise, instead of genuinely improving on it. So maybe a bit type for the C programmer and a bool type for everybody else.. :/
Yet C is an impossible ship to turn around, in terms of culture and sunken investments. Changes are virtually impossible and, even more so, highly undesirable. Instead it's time to move on and sunset C. The best C at this point is a sealed C, with a tombstone on it. Then at least it's a known entity, and then C code shall exist side by side with say Rust or Zig code, to be compiled and linked by the same compiler, without language churn. Such systems will proudly carry C into the future. Any C language changes, if needed, should focus exclusively on making that coexistence work.
Re: C meeting is over. C23 added:
#327Re: C meeting is over. C23 added:
#328For all of us that follow an "I do not want to log in to twitter" philosophy, can someone here please post an alternative link? Incidentally, I'm glad Twitter now blocks you from reading if not signed in. I'm hoping this will encourage the use of alternatives.
The Privacy Redirect addon can automatically forward you to a Twitter alternative. Sometimes the alternative instances don't work, but at least it's fully configurable, YMMV.
https://addons.mozilla.org/en-US/firefox/addon/privacy-redir...
https://chrome.google.com/webstore/detail/privacy-redirect/p...
Re: C meeting is over. C23 added:
#329Based on another thread - I think the following topic should be an interesting one for HN to chew on: If someone wanted to write systems type of programming (whether it be embedded or Unix tools or even writing a library), should they go for C (C23) or Rust today?
Nim with ARC works really well for embedded or writing system tools. Compiling to C or C++ is still handy sometimes.