Hacker News Reader

Comment by rowanG077 | Hacker News Reader

I thought the point of Fil-C was to be a drop in safe replacement of C. This project existing implies it isn't. What's going on?

View on HN

Fil-C is as compatible with C as different variants of C are with one another.

The porting effort is usually a less than if you were going from 32-bit to 64-bit for the first time. For some programs, you need zero changes.

In Qt I think the changes were stuff like:

- Use an intrinsic instead of inline assembly for cpuid.

- Change how a tagged pointer works (I.e. a 64-bit value used to store some integer bits and a pointer)

(Source: I’m the Fil-C guy and I watched the Qt porting happen from the sidelines.)

Most large C code bases aren’t really written in C. They’re written in an almost-C that includes certain extensions and undefined behavior. In this case, it uses inline assembly (an extension) and manipulating pointers as integers (undefined behavior).

While I’m always thankful when people give the broad perspective and context in a discussion, which your comment does. The specifics of this particular project’s usage of almost-C is not something I could have quickly figured out, so thanks. For such a large program, an to be as old as Qt is at this point, I find it impressive and slightly amazing that it has in some sense self-limited its divergence from standard C. It would be interesting to see what something like SQLite includes in its almost-C.

The more portable a project is, the less weird stuff it’s likely to do. The almost-C parts become more of a headache the more OSes and compilers you support. This seem pretty tame, and I’d expect SQLite to be similar. I work on some projects that only support a single OS, compiler, and CPU architecture and it’s full of dependencies on things like the OS’s actual address space (few 64-bit archs use all 64 bits).

My first job was on a large-ish software product that ran on several completely incompatible platforms - various Unixes, early Windows, IBM mainframes, etc - and window systems. At first, making all of them happy seemed like annoying busy-work.

But our code was extremely clean and extremely well-factored, because it had to be. And after porting our product to the first two or three new platforms, the later ones were much much easier to do. Lesson learned.

Since (say) the 1990s, it feels like "the world" has slowly converged to pretty much (a) the browser; (b) desktop computers - Windows, Linux, Mac; (c) phones/tablets; (d) everything else (mainframes, embedded, industrial, what have you - stuff that most people will never deal with). And portability across different platforms is no longer all that important. Which is fine, but I do miss how the need for portability forced us to work with discipline and be relentless on quality.

Afaict, there are some patterns that are not supported, like converting pointers to/from integers and doing stuff with them like bitmasks (which is a huge anti-pattern, but some code bases do it)

QtBase is C++ first of all.

Massive projects like Qt also push compilers to their limits and use various compiler-specific and platform-specific techniques which might appear as bugs to Fil-C.

It isn't entirely drop-in for all programs.

It's not done yet.

Sure fooled me. I follow his Twitter account and there isn't much he hasn't got building with it at this point. UX comes later. Amazing it's the random work of one person

I don’t think so much is fil-c itself, but from the looks of the diff it’s a new platform essentially. That can require porting existing software generally which you can read from the posted diff

The author wrote WebKit’s allocator and worked on JavaScriptCore for over a decade. I really enjoyed his posts on the WebKit blog over the years like this one on the concurrent garbage collector (2017) https://webkit.org/blog/7122/introducing-riptide-webkits-ret...

Reply on news.ycombinator.com