>Bringing that up is the only way to find out what OpenBSD developers >do consider poor quality, what they don't, and what is merely >considered a matter of style here
Thanks for your patience. I feel like I'm querying preferred coding style by this way. I also think that better way to do that is that it would be good thing if there is some reference component in source tree, and rest of the code should be aimed to same quality. In testsuite, style and implementation. I don't think that the goto is problem, even there may be possibility to make clean, readable exit using while comparison. That monster size main function is the issue and reduces readability. > mostly a matter of style, not of code quality; I think these are somewhat bonded. Especially in C, because the language is kind of unsecured gun like some Javascript. While the language lacks certain things like classes, exceptions, coroutines etc. this gap should be compensate by improving the coding conventions and checking of those can be automated too. > Obviously, you are honestly hunting for bugs. I have about million lines of build and other errors under review where I have found anomalies. Some of them seems to be errors in OpenBSD, most of them are errors in code. It just not work if I point out every single anomaly, bug, missing parameter etc. Example, I think it would be best if I write proper document where I collect ALL known issues related to POSIX conformance that can be reviewed and made to public knowledge.
