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

C meeting is over. C23 added:

twitter.com

Post reply on HN
Print view View original

351–360 of 363 posts

Re: C meeting is over. C23 added:

#351

Post by int_19h »

pjmlp wrote: post #317
int_19h wrote: post #307

Earlier quoted context omitted.

C has had a true Boolean type for over 20 years now, since C99. This time around they're merely dumping the backwards-compatible _Bool/_True/_False syntax + keyword-like #defines in , and replacing it all with proper keywords. That said, it would be nice if C caught up with Algol 68 , seeing how that's the one many of the concepts (and the corresponding keywords) are taken from. Let's start with first-class functions…

That was a kludge.

It was a syntactic kludge, perhaps, but it had good reasons - and in terms of expressive power, it's exactly the same as any other Boolean type.

Re: C meeting is over. C23 added:

#352

Post by potiuper »

nec4b wrote: post #348
potiuper wrote: post #339

Earlier quoted context omitted.

The carry flag is not a specific architectural detail; it is part of the output from the prime example of a basic electronic circuit that is the digital adder.

It is an architectural detail. MIPS for example doesn't have a carry flag. You have to do the exact same procedure in assembly on MIPS you have described in your previous comment when doing multiple word addition.

MIPS along with DEC alpha do not have adder circuits as a design goal was not to have flags. This along with the scenario of multi-precision arithmetic resulted in the implementation of multi-precision arithmetic on MIPS and DEC alpha using a form of branch like instruction with an ALU stage instead of the unavailable instructions dependent on the alternative adder circuits. The choice of having or not having a carry flag alone is not an architectural detail as the choices of [micro]architecture involve how operations are implemented in circuits/hardware. The carry flag specifically has to be considered in the context of its [the adder] circuit when making architecture decisions. The lack of control over flags leading to the inability to compile the same C program to the same assembly operations with same behavior on different hardware demonstrates that a strictly C program is unable to express a consistent portable assembly program across all hardware.

Re: C meeting is over. C23 added:

#353

Post by rixed »

pjmlp wrote: post #324
rixed wrote: post #298

Earlier quoted context omitted.

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.

Can you still write a function that accept arrays of any size, then?

Re: C meeting is over. C23 added:

#354

Post by nec4b »

int_19h wrote: post #350
nec4b wrote: post #318

Earlier quoted context omitted.

You're hung up on words. I know they made it. It was based of Ken Thomson's B. They chose it, when they could have taken some other existing language. I see great beauty and simplicity in C the same way I see it e.g. in Lisp or Javascript for that matter. I dabbled in Modula-2 and it does not offer the same feeling in my opinion. The core features of C are very powerful and simple at the same time, which is the reaso…

The core features of Modula-2 are largely the same as C + modules, but with more consistent syntax and fewer footguns (like no unsafe implicit pointer conversions), so I don't see how C can objectively possess "great beauty and simplicity" in comparison. Unless you're referring specifically to the syntax? B was also written as a hack - it was basically a minimal subset of BCPL small enough to fit in the memory of the…

Claiming something is not beautiful because it is "hacky" on HN is a bit unexpected.

For me this is beautiful:

https://briancallahan.net/blog/20220220.html

I'm sure it's just a hack to you, but you can't do that in Pascal.

I mostly like C because of what I wrote here: https://news.ycombinator.com/item?id=30404529

Re: C meeting is over. C23 added:

#355

Post by nec4b »

potiuper wrote: post #352
nec4b wrote: post #348

Earlier quoted context omitted.

It is an architectural detail. MIPS for example doesn't have a carry flag. You have to do the exact same procedure in assembly on MIPS you have described in your previous comment when doing multiple word addition.

MIPS along with DEC alpha do not have adder circuits as a design goal was not to have flags. This along with the scenario of multi-precision arithmetic resulted in the implementation of multi-precision arithmetic on MIPS and DEC alpha using a form of branch like instruction with an ALU stage instead of the unavailable instructions dependent on the alternative adder circuits. The choice of having or not having a carry…

You are basically arguing CF == !CF. On MIPS you literally have to compare your result with an operand in order to establish if there was an overflow. On Arm you just look at the status register.

When I was doing embedded development, I used C as portable assembly in practice and I know I wasn't the only one. Can you do everything an architecture enables you in a portable way? No, of course not.

Re: C meeting is over. C23 added:

#357

Post by buserror »

rwmj wrote: post #25
NotSoVeteran wrote: post #21

Earlier quoted context omitted.

The linked tweet is the 4th in a sequence. If you scroll up you should see 3 more tweets with more info.

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.

I'm the one who pointed attribute cleanup to them tho (on twitter no less) -- apparently they weren't aware of it... ? https://twitter.com/BusError/status/1481706530831585284

Re: C meeting is over. C23 added:

#358

Post by int_19h »

nec4b wrote: post #354
int_19h wrote: post #350

Earlier quoted context omitted.

The core features of Modula-2 are largely the same as C + modules, but with more consistent syntax and fewer footguns (like no unsafe implicit pointer conversions), so I don't see how C can objectively possess "great beauty and simplicity" in comparison. Unless you're referring specifically to the syntax? B was also written as a hack - it was basically a minimal subset of BCPL small enough to fit in the memory of the…

Claiming something is not beautiful because it is "hacky" on HN is a bit unexpected. For me this is beautiful: https://briancallahan.net/blog/20220220.html I'm sure it's just a hack to you, but you can't do that in Pascal. I mostly like C because of what I wrote here: https://news.ycombinator.com/item?id=30404529

"Hacked together" can mean different things. In this case, it means something slapped together on short notice with limited resources. Such things rarely tend to be beautiful. Beautiful hacks absolutely exist, but they are never hacked together in this sense.

The only thing your blog post demonstrates is that C has a built-in textual macro facility. But if you wanted the same in Pascal, you could have it just the same, by running it through the C preprocessor; or better yet, something more powerful like M4. Of course, you'd have to deal with various impedance mismatches, such as the fact that the definition of "token" is different between the preprocessor and the compiler - but that's also true of C! In fact, this discrepancy alone is quite sufficient to deem C inelegant, in my opinion.

Re: C meeting is over. C23 added:

#359

Post by robotresearcher »

MichaelBurge wrote: post #263
enedil wrote: post #198

Earlier quoted context omitted.

Manual says > If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free(). So it's not really an array of bytes of size 0.

What qualifies something as a "real" array of bytes? All RAM is an array of bytes, so any pointer to real memory(vs. virtual memory) is a pointer to an array of bytes.

The second allowed result of malloc(0), a unique pointer passable to free(), is not a pointer to an array of bytes. It can’t be used to access bytes - only compared to other pointers since it’s unique, and passed to free(). It doesn’t point to anything.

Re: C meeting is over. C23 added:

#360

Post by avar »

childintime wrote: post #326
jb1991 wrote: post #259

Earlier quoted context omitted.

> 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 std…

So, the sky is falling for unspecified reasons because booleans in C are types instead of macros.

And your proposed solution is to sunset C and move on to Rust or Zig, both of which have primitive boolean types.

Post reply on HN