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

Two types of C programmers

utcc.utoronto.ca

Post reply on HN
Print view View original

171–180 of 225 posts

Re: Two types of C programmers

#171

Post by throwawaymaths »

gavinhoward wrote: post #150
throwawaymaths wrote: post #149

Earlier quoted context omitted.

Got it. Thank you for your perspective. I can appreciate that comptime is tricky. Indeed, async zig is hard and annoying (but you're wrong about the function coloring... Here is someone's project where they call an async function alternately from a sync or async context with zero lines of code: https://youtu.be/lDfjdGva3NE?t=1999 Yielding is async and threaded is sync)

I'm not wrong. He claims that you can call functions fine in either mode if the functions are known at compile time. I never disputed that. If he tried to call those functions with possibly unknowable function pointers at runtime, I doubt it would work as well. There is a difference between compile time and runtime. At compile time, Zig can transform known functions to async to allow turn to call async functions. At…

sure, a sync function and an async function get compiled to two different things under the hood, but IMO colored/uncolored is about ux, not what happens under the hood. In go, or erlang, which don't have async coloring, you don't actually care what the system does under the hood. More generically, if a system takes a private function and can choose to inline it, you probably wouldn't moan that under the hood it's doing something different and thus "inlining is function coloring". Maybe you would.

I guess the question hinges on "just how hard" counts as "hard" for #3. I would say "not having to write an event loop because the compiler generates another version for the sync-calling-async with a single keyword" case counts as "not hard", but this is a matter of perspective. The language design still has rough edges, and you certainly ran into them, but with the function pointer stuff, I think you were really trying hard to break it to prove a specific point (this is a good thing! it will allow the team to fix it). To that point, they simply hadn't run into the specific runtime/comptime thing that you ran into, but it's pretty easy to see how exactly what you ran into can be addressed and fixed at comptime, it... just hasn't yet.

Re: Two types of C programmers

#172

Post by tialaramex »

gavinhoward wrote: post #169
tialaramex wrote: post #164

Earlier quoted context omitted.

It doesn't come with either capability, so you're adding third party tooling to get these working.

Well, sure, but that's true of any language.

Nope, when I write tests in my Rust the out of box cargo test will check those tests pass.

If I wrote inline Markdown documentation for part of the Rust code with an example, cargo test will try to build my example, and check it works - not much good having a purported "example" which doesn't even work, is it? And yet many languages don't do this.

Re: Two types of C programmers

#173

Post by GoblinSlayer »

sparkie wrote: post #51
WalterBright wrote: post #43

Earlier quoted context omitted.

D has a very nice inline assembler, bitfields, inline control, alignment control, etc. C's "register" keyword has been ignored since 1990 or so.

"register" is still supported by GCC for combined use with asm. eg, `register uintptr_t x asm ("edx");` Does D support anything like `__attribute__((section("t1")))`, so we can have the linker decide how to locate some compiled code, or computed gotos? Can we use D's inline assembler to clobber registers? I've had trouble even with clang and extended asm. For example, LLVM does not support the "g" constraint. I under…

Linux is reportedly written in C and it still has a good share of plain assembler.

Re: Two types of C programmers

#174

Post by kragen »

tialaramex wrote: post #163
kragen wrote: post #131

Earlier quoted context omitted.

4u - 5u is not undefined behavior in c; unsigned arithmetic overflow is defined to wrap around, in both directions assigning -1 to an unsigned variable has never been undefined behavior either, but implementation-defined behavior (see §6.2.1.2p3 in iso c90 or §6.3.1.3 in c99 and c11); decent compilers like gcc define it to do the obviously correct thing (see https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.…

You're correct that 4 - 5 isn't undefined in C . But there's a good reason that Rust, for example, chooses not to make its built in integer types (either signed or unsigned) wrap on overflow. Wrapping is very easy for a typical processor to implement but in most cases overflow is a mistake, so you want to report it not silently give the wrapping answer instead when the programmer apparently hasn't considered overflow…

what i'm arguing is that c compilers exist primarily to support the base of existing c code and to run it correctly and with adequate performance, not out of some unhinged notion of 'competitiveness' or to entice people into writing new programs in it

that is, i do think it's acceptable to have code that's harder to write and with worse performance, but not because of some hypothetical; rather, it's because that's how people did do it 30 years ago, and 20, and sometimes 10, and i want to run the code they wrote. this could be described as a 'retrocomputing hobby' except that that code is, for example, linux, cpython, gcc, r, libreoffice, gtk, glib, grub, bash, freetype, emacs, vim, libjpeg, libpng, postgres, mariadb, ssh, openssl, gnutls, apache, poppler, ghostscript, tex, gpg, zlib, memcached, redis, etc.

if you want to describe running vim and bash and cpython on linux as a retrocomputing hobby, i guess that's kind of defensible actually, but it comes across as wishful thinking when we don't have a working non-retro alternative yet

(moreover i have no idea why you think omitting these risky optimizations makes c code 'more buggy')

i agree that there are numerous deficiencies in c's semantics, and plausibly silent wraparound is one of them, though it seems like rust's alternative is that overflow crashes in debug builds and silently wraps like c in release builds

Re: Two types of C programmers

#175

Post by infamouscow »

jenadine wrote: post #63
infamouscow wrote: post #35

Earlier quoted context omitted.

Rust's inline assembly and configurable targets sets the standard going forward. I just wish their trademark policy relaxed some of the non-trademark related requirements making it a deal-breaker.

What does the trademark policy has to do with this? Btw the recent fuzz recently was about some proposal and not the actual one. This is the policy: https://foundation.rust-lang.org/policies/logo-policy-and-me... and I don't see any deal breaker.

The use of trademark enforcement to coerce conferences into certain policies (which might contradict local law) is a deal breaker. It also demonstrates a willingness of the foundation to use wield power for purposes completely unrelated to the language.

Re: Two types of C programmers

#176

Post by GoblinSlayer »

tialaramex wrote: post #163
kragen wrote: post #131

Earlier quoted context omitted.

4u - 5u is not undefined behavior in c; unsigned arithmetic overflow is defined to wrap around, in both directions assigning -1 to an unsigned variable has never been undefined behavior either, but implementation-defined behavior (see §6.2.1.2p3 in iso c90 or §6.3.1.3 in c99 and c11); decent compilers like gcc define it to do the obviously correct thing (see https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.…

You're correct that 4 - 5 isn't undefined in C . But there's a good reason that Rust, for example, chooses not to make its built in integer types (either signed or unsigned) wrap on overflow. Wrapping is very easy for a typical processor to implement but in most cases overflow is a mistake, so you want to report it not silently give the wrapping answer instead when the programmer apparently hasn't considered overflow…

C already has bad performance due to null terminated strings.

Re: Two types of C programmers

#177

Post by GoblinSlayer »

gavinhoward wrote: post #82

I'm the former kind: I choose C because I like it above all else. [1] That said, like the author, I'm trying to find an alternative. Well, more like I'm building my alternative because I hate Go. And Rust. And anything else. I don't know why C fits my brain, but it does. I think it's because my brain is low-level; I like messing with assembler when I get the chance to optimize. [1]: https://gavinhoward.com/2023/02/wh…

>I have special array types that I use instead of straight pointers, and those arrays store their bounds.

You cheat. You don't write C the hard way. But ok, that's an easier way to use C today.

Re: Two types of C programmers

#178

Post by mhh__ »

WalterBright wrote: post #55
sparkie wrote: post #51

Earlier quoted context omitted.

"register" is still supported by GCC for combined use with asm. eg, `register uintptr_t x asm ("edx");` Does D support anything like `__attribute__((section("t1")))`, so we can have the linker decide how to locate some compiled code, or computed gotos? Can we use D's inline assembler to clobber registers? I've had trouble even with clang and extended asm. For example, LLVM does not support the "g" constraint. I under…

The register support you describe is an extension, not really part of C. Gcc has lots and lots of C extensions, but they don't make the language simple. D's inline assembler does register management for you, i.e. it tracks register usage through the instructions, so you don't have to say which registers are read or written to. D does not support the "section" extension. I understand that certain gcc C extensions are…

LDC and GDC both have the section concept exposed as a UDA.

Re: Two types of C programmers

#179

Post by gavinhoward »

throwawaymaths wrote: post #171
gavinhoward wrote: post #150

Earlier quoted context omitted.

I'm not wrong. He claims that you can call functions fine in either mode if the functions are known at compile time. I never disputed that. If he tried to call those functions with possibly unknowable function pointers at runtime, I doubt it would work as well. There is a difference between compile time and runtime. At compile time, Zig can transform known functions to async to allow turn to call async functions. At…

sure, a sync function and an async function get compiled to two different things under the hood, but IMO colored/uncolored is about ux, not what happens under the hood. In go, or erlang, which don't have async coloring, you don't actually care what the system does under the hood. More generically, if a system takes a private function and can choose to inline it, you probably wouldn't moan that under the hood it's doi…

It can't be addressed at compile time. That's the whole point of the uncomputability of the Halting Problem.

The Zig compiler would have to have perfect knowledge of all functions that can be called anywhere. At compile time. Alan Turing proved that this is impossible.

In other words, Zig cannot address it. Ever.

Re: Two types of C programmers

#180

Post by WalterBright »

mhh__ wrote: post #178
WalterBright wrote: post #55

Earlier quoted context omitted.

The register support you describe is an extension, not really part of C. Gcc has lots and lots of C extensions, but they don't make the language simple. D's inline assembler does register management for you, i.e. it tracks register usage through the instructions, so you don't have to say which registers are read or written to. D does not support the "section" extension. I understand that certain gcc C extensions are…

LDC and GDC both have the section concept exposed as a UDA.

Good!
Post reply on HN