“Types.c” is dangerous code to bring to every project.

f32/64 makes assumptions about the platform.

Worse yet, the macros at the bottom are all functionally incorrect. Macros like MIN/MAX need to be contained in parentheses to avoid precedence errors.

For example, we take `Min(x,y)` from the code. Consider what happens if I write `ans = 2 * Min(3,4)` because of the way Min is defined that will expand to `ans = 2 * 3 < 4 ? 3 : 4` and while you may expect ans to be 3 it will infact resolve to 4.

Subtle bugs like these can creep into code and cause really hard to debug errors.

Finally, while u32 is a little faster to type than `uint33_t` it makes the project harder to read forcing the reader to learn the author’s personal c dialect. While it is a stylistic choice, I can’t see why anyone would want to sacrifice code highlighting and expressiveness for slightly less verbosity

▲

flohofwoe an hour ago | parent | next [-]

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

▲

kazinator 30 minutes ago | parent | prev [-]

> f32/64 makes assumptions about the platform.

Indeed, but, by the way, those are assumptions that some newer languages now make about the entire world.