4 ms·

C was one of those write once compile anywhere bits they used to tell us. Then when we actually tried it we found every CRT was different on all of the platfor

C was one of those write once compile anywhere bits they used to tell us. Then when we actually tried it we found every CRT was different on all of the platforms. Even something as ubiquitous as printf I think I have encountered at least 8 different versions of it. At least from compiler chain to compiler chain they are usually similar in calling conventions (but not always). But try mixing a msvcrt with a glib one and you are in for some fun... What is the nit of it is it almost works. You have a good shot at getting it to compile in a short amount of time. The rest of the work will be lots of time in ye old debugger and going over the docs for your platform. The fun part is you will find bugs that were there already, or are they just part of the platform, or were you using it wrong?

jesuscyborg 6y ago
If you want a CRT that's compile-once run-anywhere for x86 then try cosmopolitan with actually portable executable. https://justine.storage.googleapis.com/ape.html https://justine.storage.googleapis.com/ape.html It even supports fork() on windows as of a few days ago: https://github.com/jart/cosmopolitan/commit/db33973e0aae7ffc2537991e372e3fc5e59608a7 https://github.com/jart/cosmopolitan/commit/db33973e0aae7ffc...
- sumtechguy 6y ago
  That is 9 :) In effect it is yet another CRT and the idea is sound. But many times what I found was you may have one that works on say linux and windows and bsd. All the same 'code' but you dig under the covers a bit and it is a maze of ifdefs so each platform has its own quirks. For example threading between fork and createthread is on the surface not too different and you can wrap createthread with it (several libs did). But you dig into it a bit and you find portions that just do not map at all between the systems (usually with IPC and locks). At best they do not compile, slightly worse they return error codes, at worst they act like they work. A real good example of what I am talking about is the pthread library. It works up to a point but it is a very linux/bsd orientated library. There are some gaps in there from windows that just do not map and the other way around. What is worse is the docs on some of these do not talk about cross platform issues. Luckily you can see the source code of most of them and can tell what is going on. Annoying but one of the things I learned moving code between platforms is that each one has its own way of doing things. You can try to work against it or sit down and unwind what is going on, which takes time. I have even seen this sort of issue in python and java. Where you get down to some low level thing and it just is different on different platforms.
int_19h 6y ago
C is write once, compile anywhere... so long as you restrict yourself to standard C, including the library. Different implementations have different levels of standard compliance, but you are still able to say, "this will do X on any conformant hosted C89 implementation". The moment you start doing things like threads or shared libraries, yeah, it all breaks down very quickly. But that isn't standard C.
- sumtechguy 6y ago
  Even things like printf/sprintf act differently from library to library. trust me, read the docs on your lib. Most of the time they are the same but not always. It is one of those things that looks like it works but in practice there are a ton of gotchas. Most of the more mature libraries are getting better but there are some edge cases out there.
  - int_19h 6y ago
    They are different mostly because of different standards that libraries support - C90 has a baseline list of %-specifiers, but C99 added a bunch more, and then I think POSIX also has some now? Plus extensions. But I can't think of any implementation that doesn't conform to C90 in that regard. So long as you don't venture into implementation defined / UB category...

jesuscyborg 6y ago

If you want a CRT that's compile-once run-anywhere for x86 then try cosmopolitan with actually portable executable. https://justine.storage.googleapis.com/ape.html https://justine.storage.googleapis.com/ape.html It even supports fork() on windows as of a few days ago: https://github.com/jart/cosmopolitan/commit/db33973e0aae7ffc2537991e372e3fc5e59608a7 https://github.com/jart/cosmopolitan/commit/db33973e0aae7ffc...

sumtechguy 6y ago
That is 9 :) In effect it is yet another CRT and the idea is sound. But many times what I found was you may have one that works on say linux and windows and bsd. All the same 'code' but you dig under the covers a bit and it is a maze of ifdefs so each platform has its own quirks. For example threading between fork and createthread is on the surface not too different and you can wrap createthread with it (several libs did). But you dig into it a bit and you find portions that just do not map at all between the systems (usually with IPC and locks). At best they do not compile, slightly worse they return error codes, at worst they act like they work. A real good example of what I am talking about is the pthread library. It works up to a point but it is a very linux/bsd orientated library. There are some gaps in there from windows that just do not map and the other way around. What is worse is the docs on some of these do not talk about cross platform issues. Luckily you can see the source code of most of them and can tell what is going on. Annoying but one of the things I learned moving code between platforms is that each one has its own way of doing things. You can try to work against it or sit down and unwind what is going on, which takes time. I have even seen this sort of issue in python and java. Where you get down to some low level thing and it just is different on different platforms.

int_19h 6y ago

C is write once, compile anywhere... so long as you restrict yourself to standard C, including the library. Different implementations have different levels of standard compliance, but you are still able to say, "this will do X on any conformant hosted C89 implementation". The moment you start doing things like threads or shared libraries, yeah, it all breaks down very quickly. But that isn't standard C.

sumtechguy 6y ago
Even things like printf/sprintf act differently from library to library. trust me, read the docs on your lib. Most of the time they are the same but not always. It is one of those things that looks like it works but in practice there are a ton of gotchas. Most of the more mature libraries are getting better but there are some edge cases out there.
- int_19h 6y ago
  They are different mostly because of different standards that libraries support - C90 has a baseline list of %-specifiers, but C99 added a bunch more, and then I think POSIX also has some now? Plus extensions. But I can't think of any implementation that doesn't conform to C90 in that regard. So long as you don't venture into implementation defined / UB category...