> and things like that. In Java, we always had some CI server checking > various design guidelines like > > A method should have only one return statement. > > and things like this. In C this is very different due to e.g. lack of > exceptions and so. I am still failing to find semantic design guidelines > or best practices documentation for C which I believe OpenBSD developers > adhere to but never documented them somewhere. Could you please point me > to some documentation regarding this? Thank you.
I think there was some codified "rules" in the old C-lint but as compilers grew better and less code (at least the native obsd code at that) showed issues that the linters could find, it was eventually removed. Stuff like "don't use gets(), sprintf(), strcpy()" is a rule that is enforced by the linker complaining as soon as someone uses such unsafe interfaces, combined with at least the kernel being built with -Wall -Werror to make sure the user is notified as soon as known bad constructs are added. Other "rules" like "put large local vars before smaller data types in functions or structs" is seen if you read a lot of OpenBSD code, but is probably more of an optimization to spill less dummy bytes than a fixed rule, though for 64 bit arches, not having to step over single bytes to access a 64bit entity in a packed struct may or may not be a problem for strict arches, but it is so easy to avoid by having larger first and smaller later that it is just how it is done. I don't think there will be a good complete set of semantic rules, somewhat due to lots of code being of different authors and ages, but also because if there had to be rules, it would more be "learn the environment you code in" than something like "don't use goto". The latter is easy to state, and easy to "test for" using scripts and programs, but the former has far more value in making your code better. -- May the most significant bit of your life be positive.
