Finally C catches up with Algol 60 boolean types, it only took 60 years. Maybe in another 60 it will get proper strings and arrays.
Then it would become Algol, wouldn't it?
C meeting is over. C23 added:
201–210 of 363 posts
Re: C meeting is over. C23 added:
#202Earlier quoted context omitted.
UNIX free beer, hard to beat.
You do realize there is a lot of C code out there which has nothing to do with UNIX. Although I do remember when you once claimed C requires UNIX like OS to run. :)
Well, UNIX is surely responsible for C becoming popular (if not its being a thing in the first place).
Re: C meeting is over. C23 added:
#203> Support for calling realloc() with zero size (the behavior becomes undefined) OMG! Please do not add more undefined behaviour! We really need less UB, not more! What was wrong with 'implementation defined' as in C17? UB means that code that exists will now break if a new compiler decides that it can be smart. And we know how inventive this can get, right? Like removal of 'if(new_size==0) {...}' if the compiler can…
Where did you see this? I can't find it in the Twitter thread or any of the linked sources. I agree that "adding" support for something by making it UB makes no sense... as that generally would imply breaking forward-compatibility...
Re: C meeting is over. C23 added:
#204Earlier quoted context omitted.
What's being removed in C23 is the ancient K&R syntax for function definitions: int max(a, b) int a, b; { return a>b?a:b; } My understanding is that C23 does not change the meaning of function declarations. So "void foo();" remains a declaration of a function accepting an unknown number of parameters.
Wow, that's annoying. There's a bunch of old code we have that'll need updating (written that way to keep the line lengths down).
All the compilers I use have a default C version, and an optional flag to control which version to use. It's a non-issue.
Re: C meeting is over. C23 added:
#205Earlier quoted context omitted.
>Maybe in another 60 it will get proper strings and arrays. If you think this is missing, there's a big chance you don't "get" C. Also, if you don't know how to properly emulate strings in a safe way in C nowadays (for which plenty of code sample and librariesexist), your skills with the language are quite poor.
Adding so-called fat pointers to C that could be bounds checked would probably instantly eliminate a large fraction of all security issues. Of course, you can emulate these yourself, it's just a struct but not everyone does.
Adding opaque builtin struct types to C would be kind of a big deal though and would probably creep into other parts of the language and interact with them in unexpected ways. Features like fat pointers, slices, builtin dynamic arrays/strings or tagged unions would all require builtin opaque structs. This would be a whole different language (closer to Zig).
Re: C meeting is over. C23 added:
#206Earlier quoted context omitted.
Modern C compilers are written in C++. So much for C's simplicity in writing compilers.
Yes, C can be simple for writing a compiler. [0][1] No, optimisation, on the other hand, is not a simple problem. [0] https://github.com/rui314/8cc [1] https://github.com/rui314/chibicc
Naturally it can be simple, it was already a basic language when compared with what 1960's have produced.
The evolution of Bootstrapping CPL compiler + a set of basic types.
Re: C meeting is over. C23 added:
#207Earlier quoted context omitted.
Languages like Eiffel prove this isn't the case, it is a matter of proper debug tooling.
Of course, Eiffel is such a popular and widely used language, with a great toolset. /s
The amount of users doesn't change the fact of the tooling quality, but no wonder, UNIX folks tend to only take free beer, so what do they know about fine wine.
Re: C meeting is over. C23 added:
#208Earlier quoted context omitted.
Adding so-called fat pointers to C that could be bounds checked would probably instantly eliminate a large fraction of all security issues. Of course, you can emulate these yourself, it's just a struct but not everyone does.
Adding opaque builtin struct types to C would be kind of a big deal though and would probably creep into other parts of the language and interact with them in unexpected ways. Features like fat pointers, slices, builtin dynamic arrays/strings or tagged unions would all require builtin opaque structs. This would be a whole different language (closer to Zig).
It really wouldn't be that hard to do. The syntax would be trivial, and the whole point is that you want it to creep so people actually use them.
There's no overhead to doing it, but you save a bunch of bugs earlier, all for stopping conflating arrays with pointers, which is something not much code does these days anyway
Re: C meeting is over. C23 added:
#209Earlier quoted context omitted.
UNIX free beer, hard to beat.
You do realize there is a lot of C code out there which has nothing to do with UNIX. Although I do remember when you once claimed C requires UNIX like OS to run. :)
UNIX is to C like the Web is to JavaScript.
JavaScript also runs outside of the browser nowadays, so what.
Re: C meeting is over. C23 added:
#210Based 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?
Neither, unless we are speaking of kernel and drivers kind of systems programming, in which case I would pick Rust. For anything else, a language with automatic memory management.
I wish D was more widely used, as it seems to be good as a systems language, too.