It is totally fine for C code to make "assumptions about the platform".

I'm not sure where this obsession with non-existing or irrelevant target platforms is coming from that might be theoretically supported by the C standard, but are not relevant in the real world except for niche use cases which the library author might not care about (like some extremely limited embedded CPUs). E.g. not every C library needs to support every target platform just because that target platform has a C compiler, and all code (not just C code) should be considered broken anyway until it is actually tested on a specific platform (and in that case any problems that show up are trivial to fix).

You're right about the macro thing of course.

The typedef-thing is arguable, I would at least try to not let such custom typedefs over basic types leak into the public API of the library where they could collide with typedefs of other libraries (e.g. all public types of a library should have at least a prefix which makes name collisions with other libraries unlikely).

▲

1718627440 an hour ago | parent [-]

Because C is fundamentally defined for an abstract machine. People just ignoring portability and writing machine-specific code reek after actually not understanding other fundamental properties of C and are as such prune to writing a lot of undefined behaviour. C is fundamentally abstract from the machine and ignoring that will bring you in all kind of nasty situations, even if the code happens to run fine, because the compiler translated it accidentally in the naive way you expected it to.

Of course there are also the people who know what C is and make explicit choices about the compiler and the platform. But then they are often explicit about that and say that they are NOT writing C, but e.g. gnu11 on arm64. Then you also know that you can't just change the compiler and platform and happen to be fine.

	▲	flohofwoe 44 minutes ago \| parent [-]
		> Because C is fundamentally defined for an abstract machine. This is more like a guideline than actual rule ;) (e.g. the C standard is also full of implementation defined behaviour, and that's fine). Instead of obsessing over theoretical C standard details, people should build their code with "-Wall -Wextra" (that's the absolute minimum), maybe -pedantic (which however disables a lot of useful non-standard extensions that are accepted by most popular compilers), run the code through a static analyzer, and test with ASAN, UBSAN and TSAN (and nowadays, also let an LLM do a bug scan over the code). When all those things are clean, the code is in pretty good shape and will most likely survive porting to a new target platform or compiler. UBSAN is also pragmatic enough to focus on the 'important' UB, and ignore the 'irrelevant' types of UB.