Earlier quoted context omitted.
...except it just changed. And you will be forever left writing insecure memory unsafe code.
One change per decade is not a change.
More than once per decade: C11, C17, C23
C meeting is over. C23 added:
131–140 of 363 posts
Re: C meeting is over. C23 added:
#132> 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…
They'd better not convert that to undefined behavior!
First, the specification for malloc() says you can call it with size 0 and it will still return a pointer to zero bytes; this means an array of bytes having size zero is legal.
Second, having the compiler detect when realloc() is called with size zero changes what should be a library call into an intrinsic, whose very presence in the code is determined by the value of its arguments[0]. If you're going to do that you might as well just put exceptions in the language!
[0] Most compilers assume UB "can't happen" and just remove the offending code altogether.
Re: C meeting is over. C23 added:
#133> typeof(...) is standard
I thought C++11 went with decltype because typeof was implemented by compilers as an extension with various subtle semantic differences than what they wanted.
I wonder why the C committee went with typeof instead of decltype?
Re: C meeting is over. C23 added:
#134Earlier quoted context omitted.
The word "portable" means a subset of everything possible. Do you think every CPU architecture supports SIMD?
> The word "portable" means a subset of everything possible. Exactly; for example, C has single precision and double double precision floating point, 64 bit types, and complex arithmetic because every CPU architecture has those built-in.
No, but those things can be easily emulated on every hardware or simply not used. One more reason to use C instead of plain assembly.
Re: C meeting is over. C23 added:
#135Earlier quoted context omitted.
C++ requires to devote your life to it but you can learn C and spend a year using it and suddenly you have a dangerous but powerful tool in your toolbox forever.
It's not like C++ is always the only alternative, see e.g. Rust which is way simpler
I agree that Rust is simpler than C++ (in some ways), but I’d say it is far more complex than C.
Re: C meeting is over. C23 added:
#136Earlier quoted context omitted.
There is where you went off rails, with greetings from ACM. https://queue.acm.org/detail.cfm?id=3212479
I'm so glad that you have linked this article from Chisnall. I can now ask you in what ways is the abstract model of a machine on which assembly language operates on, different from the one on which the C language operates on? This is the claim which started this thread: >>C is a portable alternative to assembly language.
C's abstract machine is leaky and full of surprises when UB comes into play for one.
Second when people talk about C being portable Assembly, they mistakenly assume to know what comes out of the compiler's backend.
Third, unless we are speaking about PDP-11 like CPUs, modern CPUs have tons of capabilities not exposed to ISO C.
Finally, since 1958 there are portable alternatives to Assembly in systems programming with JOVIAL being one of the first remarkable ones, yet another thing that C did not invent.
Re: C meeting is over. C23 added:
#137For 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.
Re: C meeting is over. C23 added:
#138> typeof(...) is standard I thought C++11 went with decltype because typeof was implemented by compilers as an extension with various subtle semantic differences than what they wanted. I wonder why the C committee went with typeof instead of decltype?
IIRC typeof is implemented in the same way by all compilers that have it, but it had some subtle differences with what the committee wanted. The differences presumably do not matter for C, in fact I think it was something related to references.
Re: C meeting is over. C23 added:
#139> 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
Re: C meeting is over. C23 added:
#140Earlier quoted context omitted.
Thanks - Twitter UI is terrible. I'm glad the terrible "defer" suggestion didn't make it, but unfortunate that they didn't standardise the existing and widely used attribute cleanup.
This is off topic, but I don't think the problem is just that the Twitter is terrible. If you want to link to a thread, you should click on the first tweet of that thread and copy its url. It's easy to see the rest of the thread: just scroll down. If you want to link to one tweet in a thread you should click on that tweet and copy its url. The person who posted the link to HN did the latter, while they should have do…
Twitter is bad if you don't have a twitter account. It'd be great if HN could change twitter links to go through nitter.net