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

C extensions, portability, and alternative compilers

lemon.rip

Post reply on HN
Print view View original

91–97 of 97 posts

Re: C extensions, portability, and alternative compilers

#91

Post by fuhsnn »

upvotrsuper wrote: post #45
fuhsnn wrote: post #14

For those who are making indie C compilers that don't pretend to be __GNUC__ but want to compile real world projects, slimcc's test script[1] and platform header hacks[2] might save you some time. [1] https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thi... [2] https://github.com/fuhsnn/slimcc/blob/main/slimcc_headers/pl... Some more fun stories: - Game projects default to using SIMD so for example SDL and STB…

Although I don't use slimcc, I follow its development because I learn so much about C - even though I've been using C and C++ for over 30 years. https://github.com/fuhsnn/slimcc/blob/main/scripts/linux_thi... is an incredible piece of work. I can't imagine how many hours it took to assemble this collection. If slimcc can pass that project list torture test, then surely it's bulletproof.

It did take many hours, but I learnt a lot in the process, found some bugs to report, and watched plenty of series concurrently. Overall it's a nice and worthwhile hobby!

Re: C extensions, portability, and alternative compilers

#92

Post by kjs3 »

pif wrote: post #87
kjs3 wrote: post #85

Earlier quoted context omitted.

How dare anyone spend time on things you don't approve of. /s

Spending time on your hobby is wondwerful. Expecting the world to consider your hobby important is arrogant.

Much like saying It's time to leave (your hobby) in the history books. But it's obvious that the distinction and thus the irony is completely lost here.

Re: C extensions, portability, and alternative compilers

#93

Post by kscarlet »

eska wrote: post #58
kscarlet wrote: post #48

I think the Common Lisp ecosystem sets a good example of how a dozen of implementations move ahead together. Implementations experiment with extensions, the really useful ones get implemented multiple times, and some portability library emerges as de-facto standard if it's good enough. You can watch the result in https://portability.cl/ , the language is evolving like never before even if the standard committee has d…

Isn’t this only possible in lisp due to the strong foundations of meta programming allowing the implementation of language features as user libraries?

Not directly. Every "extensions" listed above cannot be implemented as user libraries, that's why these back and forth process between implementation extensions and portability user libraries need to happen to reach a de-facto standard. Otherwise the user libraries become de-facto standard themselves, like ASDF the build system, Trivia the pattern matcher...

But I think the power dynamics is crucial. In the Lisp ecosystem the users have great power, (and there are dozens of implementations,) so it's not like one or two implementation decides what everyone is gonna use and everyone just lives with it.

Re: C extensions, portability, and alternative compilers

#95

Post by fc417fc802 »

MereInterest wrote: post #86
fc417fc802 wrote: post #43

Earlier quoted context omitted.

The ideal isn't feature flags (ie FOO_SUPPORTED) but rather feature tests (ie COMPILES( foo( int ) ) ). Yet another reason why languages with proper metaprogramming capabilities are better.

The problem with feature tests is that you then rely on the test code being correct. A typo in the feature test can erroneously be interpreted as lack of that feature. One step of the 2024 supply-chain attack on xz utils was to disable a security feature by introducing a feature test with an intentional typo. Even knowing that this commit[0] contains an intentional typo, I had to re-read the diff a few times to actua…

I don't see the problem? You need to test your feature test code just like anything else. Bugs can show up anywhere after all. This is the sort of code that lives deep in a utility library and rarely if ever changes.

It's an interesting point though that the parts of a program that don't fail loudly are prone to having bugs go unnoticed.

Re: C extensions, portability, and alternative compilers

#96

Post by einpoklum »

matheusmoreira wrote: post #81
account42 wrote: post #66

Earlier quoted context omitted.

The definition of a strawman.

Not at all. The point was that using systemd is somehow "mandated". It's not, people chose systemd because it's actually better and made life easier compared to some POSIX nonsense. The point was that this non-existent "mandate" caused a "bifurcation" from "standards-based" software to Linux-specific. If anything is being "mandated" here, it's the POSIX compliance. Nobody is obligated to follow this like it's some so…

> It's not

If you're using RedHat or Debian and most of their derivative distributions, it is.

> people chose systemd because it's actually better

No, they did not. Most people did not choose systemd, their Linux distributions did.

RedHat chose their own system for their own distributions; on Debian, a controvertial process foisted it onto the distribution using gaslit rhetoric; and I don't know much about the process elswehre.

> The point was

That was not the point.

> It's just not "standards compliant"

This is the straw man you've created. Neither my post nor most critique of systemd regards "standards compliance".

Re: C extensions, portability, and alternative compilers

#97

Post by matheusmoreira »

einpoklum wrote: post #96
matheusmoreira wrote: post #81

Earlier quoted context omitted.

Not at all. The point was that using systemd is somehow "mandated". It's not, people chose systemd because it's actually better and made life easier compared to some POSIX nonsense. The point was that this non-existent "mandate" caused a "bifurcation" from "standards-based" software to Linux-specific. If anything is being "mandated" here, it's the POSIX compliance. Nobody is obligated to follow this like it's some so…

> It's not If you're using RedHat or Debian and most of their derivative distributions, it is. > people chose systemd because it's actually better No, they did not. Most people did not choose systemd, their Linux distributions did. RedHat chose their own system for their own distributions; on Debian, a controvertial process foisted it onto the distribution using gaslit rhetoric; and I don't know much about the proces…

> If you're using RedHat or Debian and most of their derivative distributions, it is.

Use a better distribution.

Arch Linux has entire wiki pages dedicated to alternative init systems. Anyone can download, install and use OpenRC or whatever they want if they really care enough. People actually took the time to document the process.

Linux is whatever you make of it. There is nothing stopping you from installing whatever you want. I could write an init today and start using it immediately. I don't need anybody's permission to do it.

> Most people did not choose systemd, their Linux distributions did.

By "people" I meant the people who make and maintain the distributions. They're the ones who actually choose what to ship in their projects. Users either accept it, look elsewhere or take on the maintenance burden unto themselves.

No doubt they chose systemd because it made their lives monumentally easier. Maintaining my own computer with systemd is pretty much painless. I don't even remember what it was like before.

> Neither my post nor most critique of systemd regards "standards compliance".

> we've started to see this sort of bifrucation of a lot more FOSS away from being standard-based and multi-platform to being Linux-specific.

No idea what "standard" you're referring to if not POSIX.

Post reply on HN