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

31–40 of 97 posts

Re: C extensions, portability, and alternative compilers

#31

Post by matheusmoreira »

whizzter wrote: post #10
formerly_proven wrote: post #3

Earlier quoted context omitted.

For a bunch of software categories there isn't really much point to support Windows at all these days. We've had "developed for unix, ported to Windows" software for a long time and it often doesn't work that well, because the agreement even for fairly basic stuff is not that large between the two.

1: My point isn't "developer on unix, ported to Windows", it's "developed on linux, maybe works elsewhere". 2: You could easily compile Samba yourself for FreeBSD in the past, last time I tried a new version it broke in what I remember being due to linux-isms (yes there is ports, but being reliant on older versions if ports maintainers can't keep up isn't a good thing). 3: The only "fairly basic" stuff that's hugely…

Superiority complex?

How many times have we been told that we're entitled freeloaders for expecting Linux compatibility work from others? Insulted by people who use dominant platforms that get all the commercial support while we get literally nothing? Reduced to reverse engineering stuff with no documentation and zero help?

Pretty wild to watch this unfold. Now that Linux is finally coming out ahead, as it should, because people are finally writing software for it... Suddenly we're the bullies.

Re: C extensions, portability, and alternative compilers

#32

Post by rurban »

einpoklum wrote: post #28
rurban wrote: post #16

I just implemented a fast small compiler rcc to compete against tcc, and these glibc header quirks were simply fixed in the same way clang does it. By defining all gcc predefines and implementing all gcc extensions. Needed a day. And my headers are clean compared to glibc. The others in this league are slimcc, kefir and cproc. No other compilers can parse glibc headers. tcc has this special exception.

If the codebase is small, and the dependencies are minimal, you might look into trying to integrate your rcc in "bootstrapping" flows, which currently often rely on tcc as a stepping stone towards gcc. And perhaps even being able to skip gcc 4.7 in favor of your compiler, if it's capable of, say, compiling a modern gcc to work even suboptimally.

tcc is pretty good for this.

What I want to explore is cheap and fast optimizations, without SSA and data flow tracking. I have huge sources files compiled to 25MB .o files, which should need to be compiled in less than 5m. So far only tcc can do that. But I have now consteval and deadcode elimination for free. Which tcc cannot do.

Re: C extensions, portability, and alternative compilers

#33

Post by justin66 »

matheusmoreira wrote: post #31
whizzter wrote: post #10

Earlier quoted context omitted.

1: My point isn't "developer on unix, ported to Windows", it's "developed on linux, maybe works elsewhere". 2: You could easily compile Samba yourself for FreeBSD in the past, last time I tried a new version it broke in what I remember being due to linux-isms (yes there is ports, but being reliant on older versions if ports maintainers can't keep up isn't a good thing). 3: The only "fairly basic" stuff that's hugely…

Superiority complex? How many times have we been told that we're entitled freeloaders for expecting Linux compatibility work from others? Insulted by people who use dominant platforms that get all the commercial support while we get literally nothing? Reduced to reverse engineering stuff with no documentation and zero help? Pretty wild to watch this unfold. Now that Linux is finally coming out ahead, as it should , b…

> Now that Linux is finally coming out ahead

Where have you been for the last quarter century?

Re: C extensions, portability, and alternative compilers

#34

Post by fanf2 »

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.

https://www.kernel.org/doc/html/latest/kbuild/llvm.html

Re: C extensions, portability, and alternative compilers

#35

Post by matheusmoreira »

justin66 wrote: post #33
matheusmoreira wrote: post #31

Earlier quoted context omitted.

Superiority complex? How many times have we been told that we're entitled freeloaders for expecting Linux compatibility work from others? Insulted by people who use dominant platforms that get all the commercial support while we get literally nothing? Reduced to reverse engineering stuff with no documentation and zero help? Pretty wild to watch this unfold. Now that Linux is finally coming out ahead, as it should , b…

> Now that Linux is finally coming out ahead Where have you been for the last quarter century?

I was using Linux on my machines despite all the difficulties involved.

Re: C extensions, portability, and alternative compilers

#36

Post by rurban »

dooglius wrote: post #12
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…

The preceding comment indicates that the intent is to support other compilers. I think a better approach is to define __glibc_attribute__ based on compiler support and to stick to that within glibc since there's no reason to think that another compiler's attributes have the same semantics as GNU C's.

That ship sailed already. You simply have to mimic gcc.

Which is at least better than with MSVC, where they did everything differently, and only half of it.

Re: C extensions, portability, and alternative compilers

#37

Post by Maxatar »

fanf2 wrote: post #34
kouosi wrote: post #30

Earlier quoted context omitted.

> 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.

https://www.kernel.org/doc/html/latest/kbuild/llvm.html

That's a good point, the more precise statement is that Linux exclusively uses gnu11 to compile.

Clang happens to implement gnu11, I think it's the only non-GCC compiler to do so.

Re: C extensions, portability, and alternative compilers

#38

Post by bmink »

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…

Yes, while the article makes some good points the first paragraph was puzzling.

Re: C extensions, portability, and alternative compilers

#39

Post by jstimpfle »

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…

What do you even miss, honestly works fine for me? In terms of platform APIs, I prefer the Windows ones on Windows anyway

Re: C extensions, portability, and alternative compilers

#40

Post by drwu »

jstimpfle wrote: post #39
rwmj wrote: post #22

Earlier quoted context omitted.

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…

What do you even miss, honestly works fine for me? In terms of platform APIs, I prefer the Windows ones on Windows anyway

Complex numbers, for example. Also, C preprocessor expands macros differently on MSVC.
Post reply on HN