On 12/12/24 16:38, Janne Johansson wrote: >> 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. >
I am quite tired now and will need some sleep. I will try to come up with an example the next day. One using pointer syntax and a while loop and one using array syntax and a for loop. The first will make the compiler produce something similar to what I would have written in assembly directly. The latter will magically make the compiler start generating SIMD instructions. I may be very wrong about this and things just happened out of luck, but I'll give it a try the next day and report back. Those linker warnings about using questionable functions are of great help already, but this is not what I am heading after. Lets see if I can come up with an example tomorrow. -- Christian
