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

41–50 of 97 posts

Re: C extensions, portability, and alternative compilers

#41

Post by jeltz »

einpoklum wrote: post #25
whizzter wrote: post #2

One of my pet-peeves with C projects is that it's so often more or less "works on my machine" when written by Linux users (as a Windows and FreeBSD user it often hits you on both those platforms). The article highlights a typical piece: #if !(defined __GNUC__ || defined __clang__ || defined __TINYC__) # define __attribute__(xyz) /* Ignore */ #endif There is no reason that !defined check to not include a check for __a…

systemd is indeed the bane of Linux, and a pain in the ass for a lot of FOSS. Once the main distributions made it mandatory to install (not just the default, but mandatory) - 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. That said - I think a rule-of-thumb one can follow is that any inclusion of a file with a directory prefi…

No, systemd is not the bane of Linux. What existed before it was much worse. Upstart was a totally broken mess and almost all sysv init scripts contained several bugs.

I don't like systemd but it is a lesser evil.

Re: C extensions, portability, and alternative compilers

#42

Post by bigbadfeline »

rwmj wrote: post #22
whizzter wrote: post #2

One of my pet-peeves with C projects is that it's so often more or less "works on my machine" when written by Linux users (as a Windows and FreeBSD user it often hits you on both those platforms). The article highlights a typical piece: #if !(defined __GNUC__ || defined __clang__ || defined __TINYC__) # define __attribute__(xyz) /* Ignore */ #endif There is no reason that !defined check to not include a check for __a…

MSVC support for C is fairly terrible. For the projects we write that are portable to Windows we insist you use GCC or Clang on Windows. No one has time to deal with the lack of even standard C1x/C2x features (never mind useful extensions like attribute cleanup). Surprised about FreeBSD. My experience is that porting Linux software is usually pretty easy as long as it's not using some Linux-only feature (io_uring for…

> Surprised about FreeBSD. My experience is that porting Linux software is usually pretty easy as long as it's not using some Linux-only feature (io_uring for instance).

I'm not sure why you're surprised, the parent of you comment clearly stated

"on FreeBSD you often run into systemd dependencies or other non-posix behaviors"

which means, software written for Linux often uses "Linux-only features" such as systemd and other non-posix dependencies that are foreign to the BSDs and traditional UNIX. Thus, it shouldn't be surprising that Linux software is hard to port to the BSDs.

Linux used to be a pretty good UNIX, I'm not sure what it is now.

Re: C extensions, portability, and alternative compilers

#43

Post by fc417fc802 »

ventana wrote: post #24
meghprkh wrote: post #15

Why would they not do something like? + #if !(defined __GLIBC_COMPILER_SUPPORTS_ATTRIBUTES__) - #if !(defined __GNUC__ || defined __clang__ || defined __TINYC__) # define __attribute__(xyz) /* Ignore */ #endif (or probably a more fine grained for each attribute they try to use) Considering such checks are fairly conventional in downstream C++ libraries based on compilers (for example checking OS platform or compiler,…

I have no knowledge of this specific "why", but my general experience shows that feature flags, while almost universally better than checks for the specific software version in hope that it has proper support for a feature, appear only as a replacement to platform / software detection, after a few years of struggle. It's probably just natural for software developers (myself included), whenever only FooZoid v5 support…

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.

Re: C extensions, portability, and alternative compilers

#44

Post by einpoklum »

kouosi wrote: post #30
einpoklum wrote: post #26

> Anyone who's written C knows that full ISO C standard-adhering code is an impractical rarity. I've written quite a bit of C code and do not know that to be a rarity. Especially when it comes to libraries rather than applications, and FOSS as opposed to proprietary code. > Most real world C code out there relies on non-standard behaviors and language extensions to varying extents Maybe it depends on which domain you…

> And of course, once your code does not target just one single machine then you're forced to have to worry about portability and standard compliance etc. Well linux exclusively usages gcc to compile.

Yes, sorry, mistype, that should have been "single kind of machine" or "single operating system".

Re: C extensions, portability, and alternative compilers

#45

Post by upvotrsuper »

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.

Re: C extensions, portability, and alternative compilers

#46

Post by einpoklum »

jeltz wrote: post #41
einpoklum wrote: post #25

Earlier quoted context omitted.

systemd is indeed the bane of Linux, and a pain in the ass for a lot of FOSS. Once the main distributions made it mandatory to install (not just the default, but mandatory) - 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. That said - I think a rule-of-thumb one can follow is that any inclusion of a file with a directory prefi…

No, systemd is not the bane of Linux. What existed before it was much worse. Upstart was a totally broken mess and almost all sysv init scripts contained several bugs. I don't like systemd but it is a lesser evil.

systemd is not an init system; it _contains_ an init system. It is a huge swatch of the whole userspace of a Linux system up to shell or GUI sessions - and having an init system was just an excuse; and in fact, the systemd point brought up in the linked article is unrelated to init systems.

There are quite a few init systems: The venerable sysvinit, runit, s6, openrc and others. You don't like upstart? Ok, choose another one, there are many. Here is a comparison table by the Gentoo folks:

https://wiki.gentoo.org/wiki/Comparison_of_init_systems

As for the claim of "almost all sysvinit scripts contained several bugs" - that's both hyperbole and false. Plus, you seem to be implying that systemd has not been troubled by bugs, which of course it has (and that does not disqualify it; the fundamental design and organizational nature as a project are the disqualifiers).

Re: C extensions, portability, and alternative compilers

#47

Post by neonz80 »

matheusmoreira wrote: post #29
whizzter wrote: post #2

One of my pet-peeves with C projects is that it's so often more or less "works on my machine" when written by Linux users (as a Windows and FreeBSD user it often hits you on both those platforms). The article highlights a typical piece: #if !(defined __GNUC__ || defined __clang__ || defined __TINYC__) # define __attribute__(xyz) /* Ignore */ #endif There is no reason that !defined check to not include a check for __a…

> One of my pet-peeves with C projects is that it's so often more or less "works on my machine" when written by Linux users (as a Windows and FreeBSD user it often hits you on both those platforms). Windows users singling out Linux users for not catering to their platform. How the times change... > you often run into systemd dependencies or other non-posix behaviors Not a problem. POSIX is irrelevant, systemd is grea…

> Windows users singling out Linux users for not catering to their platform. How the times change...

In my experience this was a problem over 25 years ago when I developed for Solaris and other non-Linux operating systems.

Re: C extensions, portability, and alternative compilers

#48

Post by kscarlet »

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 dissolved nearly 40 years ago!
Post reply on HN