Notes by djb on using Fil-C • Hacker News Board

Re: Notes by djb on using Fil-C

#261

Post by vacuity » Tue, Nov 04, 2025, 2:31 PM UTC

kasabali wrote: post #257

vacuity wrote: post #136

Earlier quoted context omitted.

Hacker News is not a place where any one group brigrades a thread. There are people who prefer C who don't want a GC, people who prefer Rust who don't want C, people who prefer Rust who agree with Fil-C for legacy C, people who don't prefer C or Rust and may use languages with GC.... We all have interests and face people who denigrate them in bad faith. If you have specific objections to inaccurate statements in this…

> Hacker News is not a place where any one group brigrades a thread Sweet summer child

I'm not saying that people don't comment in bad faith here. But if someone's first thought upon seeing significant negativity is that a coordinated, massive campaign is occurring, that someone is probably wrong. Commenting in that vein also harms discussion. If Hacker News is to foster good discussion, then simply not being a troll or ideologue is not sufficient.

There really are many people here, with largely diverse opinions. Don't lump people together unless they lump themselves together.

Re: Notes by djb on using Fil-C

#262

Post by Ar-Curunir » Tue, Nov 04, 2025, 11:43 PM UTC

johnisgood wrote: post #258

Ar-Curunir wrote: post #255

Earlier quoted context omitted.

(a) that is a fairly easy to understand piece of code. Are you complaining about the definition of the inner function? (b) the equivalent C code would look pretty similar. (c) this is not cryptographic code

(a) I'm complaining about the messed up syntax and symbol soup. https://github.com/ioccc-src/winner/blob/master/2024/burton/... This code is fairly easy to understand, too, then. (b) No, it would definitely not look "pretty similar". (c) So what? You talked about abstractions in cryptographic code. Abstractions are layers to hide things. That is bad in crypto code.

Hiding things is totally great in crypto code! When I’m implementing signature verification, I shouldn’t have to worry how the underlying, eg, field or elliptic curve algebra is implemented!

In fact there have been many crypto bugs which insufficiently abstract this kind of stuff away.

Re: Notes by djb on using Fil-C

#263

Post by kragen » Thu, Nov 06, 2025, 2:25 AM UTC

Findecanor wrote: post #260

Findecanor wrote: post #178

Earlier quoted context omitted.

Both Fil-C and CHERI rely on a concurrent GC/a GC-like task to find and invalidate all pointers to free()'d memory objects (in "quarantine") before putting them back into the memory pool. The difference is that because Fil-C has bounds in each object's header, it only has to nullify it to remove access whereas in CHERI a quarantined object can still be accessed through any pointer that hasn't been invalidated yet. I'…

Follow-up: CHERioT (Microsoft's RV32E-based variation for embedded systems) does have a quarantine tag bit per 64-bit word of memory. The base address' bit is checked on capability load by the CPU's "Load filter".

Thank you!