News for hackers. Stuff that matters.
Re:Fil-C: A memory-safe C implementation by pizlonator on Tuesday October 28, 2025 @07:21PM (#45740599)
That was my idea and I wrote a good chunk of the compiler and runtime.
Re:Fil-C: A memory-safe C implementation by kragen on Tuesday October 28, 2025 @07:25PM (#45740637)
(For those who didn't make the connection, pizlonator also wrote Fil-C.)
Re:Fil-C: A memory-safe C implementation by frumplestlatz on Tuesday October 28, 2025 @10:30PM (#45741934)
I don’t want to out myself or simply cast vague aspersions against which one cannot easily defend, so I’ll just say that was not the reality on the ground.
Re:Fil-C: A memory-safe C implementation by pizlonator on Tuesday October 28, 2025 @11:08PM (#45742182)
Sounds like you weren't there
Re:Fil-C: A memory-safe C implementation by frumplestlatz on Tuesday October 28, 2025 @11:40PM (#45742360)
Okay. I really don’t want to break HN rules, but it’s interesting to see that your time away hasn’t tempered your myopic ego one bit.
Re:Fil-C: A memory-safe C implementation by jibal on Wednesday October 29, 2025 @01:59AM (#45743158)
That breaks HN rules.
Re:Fil-C: A memory-safe C implementation by kragen on Wednesday October 29, 2025 @02:10AM (#45743219)
(But revealing your identity would not.)
Re:Fil-C: A memory-safe C implementation by actionfromafar on Wednesday October 29, 2025 @06:42AM (#45745033)
You don't want to - so you did it anyway?
Re:Fil-C: A memory-safe C implementation by geocar on Wednesday October 29, 2025 @04:41AM (#45744238)
Why isn't the compiler frontend called fucc?
Re:Fil-C: A memory-safe C implementation by pizlonator on Wednesday October 29, 2025 @08:34AM (#45746012)
I was so tempted to call it that
Re:Fil-C: A memory-safe C implementation by ctrust on Wednesday October 29, 2025 @11:46AM (#45748436)
It isn't too late!
Re:Fil-C: A memory-safe C implementation by RBO2 on Wednesday October 29, 2025 @10:05AM (#45746998)
Why not call it secc ("sexy") ?
Re:Fil-C: A memory-safe C implementation by pizlonator on Wednesday October 29, 2025 @11:30AM (#45748162)
It's poor form to put the word "secure" (or any derivative of it) into a product that aims to provide more security.

Reason: there's no solution to the security problem. Fil-C doesn't solve security. Does it make things more secure? Yes! But there will always be more security issues. So imagine if I had called it "Secure C" (and then had a sexy compiler), and 10 years from now someone finds a comprehensive solution to the string injection problem in Secure C. What do they call their thing? Securer C? Secure C Pro? Secure Secure C?

Re:Fil-C: A memory-safe C implementation by RBO2 on Wednesday October 29, 2025 @11:51AM (#45748521)
These are good points but no name is ever perfect. Just felt that secc was more memorable and would offer more levarage to this great project :-)
Re:Fil-C: A memory-safe C implementation by kragen on Wednesday October 29, 2025 @02:07PM (#45750747)
"Filthy" is already extremely memorable.
Re:Fil-C: A memory-safe C implementation by kragen on Wednesday October 29, 2025 @01:48PM (#45750490)
I agree. I'd add that security is always relative to not just an existing level of security but to a threat model. There are threat models relative to which Fil-C doesn't make things more secure. (I can't think of one under which Fil-C makes things less secure, though.)

A similar criticism applies to "new". Newcastle is named after a castle built 945 years ago. Neuchâtel is named after a castle built 1014 years ago. Xavier (from Basque "etxeberri", "new house") is named after a castle built in the 10th century. Windows NT "new technology", etc.

Re:Fil-C: A memory-safe C implementation by jibal on Thursday October 30, 2025 @01:25AM (#45756697)
Re:Fil-C: A memory-safe C implementation by avadodin on Wednesday October 29, 2025 @05:58AM (#45744716)
Forgive me for not putting in the effort this deserves, but the description of pointers in this thread reads a lot like the current description of Fil-C pointers from the main site.

What is the 64-bit-presenting representation of pointers in Fil-C?

That is, what does %p return and how does that work as a pointer?

Re:Fil-C: A memory-safe C implementation by pizlonator on Wednesday October 29, 2025 @08:34AM (#45746006)
Re:Fil-C: A memory-safe C implementation by avadodin on Wednesday October 29, 2025 @08:44PM (#45755073)
Re-reading tfm, it definitely had an answer to my dumb question(basically the same as any regular C pointer), but I still get the feeling that the explanations make jumps that may be obvious to you but absolutely not to me.

I sort of get a sense of what the flight pointers do after reading the linked page with the assembly listings( which on mobile looks like you're discussing hex dumps until one tries side scrolling, btw ) but my brain would expect something along the lines of: "this is the flight pointer and this is how it is managed for local variables, global variables, etc. This part of it is what your C program sees" at the beginning of the invisicaps article rather than "pointers are 64 bit like in regular C proceeds to talk about a tuple containing two pointers"(at least that's how it reads to me).

Probably just laziness on my part.

Re:Fil-C: A memory-safe C implementation by pizlonator on Wednesday October 29, 2025 @08:55PM (#45755137)
That’s really good feedback about how to better talk about this stuff. Thank you!

InvisiCaps are counterintuitive. Took me a while to come up with them. I still haven’t found a really clean way to explain them to folks