21–29 of 29 posts
Is this the official sudo repository? https://www.sudo.ws/repos/sudo/file/f75f786eddd5 It has more than 10 thousand commits, ~600 files, and close to 11MB of C code. Also, the code seems to have no unit tests, the main file is 1.4K lines long, has quintuple-nested conditionals and liberally uses goto statements. Am I missing something here?
Is this the official sudo repository? https://www.sudo.ws/repos/sudo/file/f75f786eddd5 It has more than 10 thousand commits, ~600 files, and close to 11MB of C code. Also, the code seems to have no unit tests, the main file is 1.4K lines long, has quintuple-nested conditionals and liberally uses goto statements. Am I missing something here?
The former isn't significantly different than exceptions, except that it's probably less likely than exceptions to cause unexpected errors because its more explicit.
At a very quick glance that's what the goto usage looks like in the codebase. This isn't to say that I think it's all appropriate, but if it was, I don't think your comment would have been any different.
There are a lot of really hot opinions on coding style and various fashions, but very little of it is backed up with research that connects it to defect rate.
I agree it would be good if sudo had an internal test suite (particularly system tests and fuzzing harnesses)-- but you also shouldn't discount the large amount of testing that goes on against it externally through both usage and external efforts.
Is this the official sudo repository? https://www.sudo.ws/repos/sudo/file/f75f786eddd5 It has more than 10 thousand commits, ~600 files, and close to 11MB of C code. Also, the code seems to have no unit tests, the main file is 1.4K lines long, has quintuple-nested conditionals and liberally uses goto statements. Am I missing something here?
Some of the points you raise are matters of style (I have files that are 10k lines long and think they are better that way; also I don't think unit tests are as useful as claimed), but yeah, when you have 600 files and 11MB of code to do something that is supposed to be simple and also is security-critical ... you have a big problem.
Whether you prefer this practice stylistically or not doesn't change the fact that it is objectively worse in terms of code quality and maintainability, even if you are able to compensate for those deficits with your own skill/experience.
You might have no problem successfully navigating that code for which you've already built a complete mental model around, but any future collaborators or inheritors of that code will have to waste hours or days rebuilding that mental model which you could have just codified in the structure of the source code.
Earlier quoted context omitted.
Some of the points you raise are matters of style (I have files that are 10k lines long and think they are better that way; also I don't think unit tests are as useful as claimed), but yeah, when you have 600 files and 11MB of code to do something that is supposed to be simple and also is security-critical ... you have a big problem.
> I have files that are 10k lines long and think they are better that way Whether you prefer this practice stylistically or not doesn't change the fact that it is objectively worse in terms of code quality and maintainability, even if you are able to compensate for those deficits with your own skill/experience. You might have no problem successfully navigating that code for which you've already built a complete menta…
That's an opinion. There's nothing objective about the assertion that many small files are inherently more secure. However, that many small files and one large file have equivalent power, can express all the same programs, and can be equally secure or insecure... those actually are all objective facts.
Earlier quoted context omitted.
> I have files that are 10k lines long and think they are better that way Whether you prefer this practice stylistically or not doesn't change the fact that it is objectively worse in terms of code quality and maintainability, even if you are able to compensate for those deficits with your own skill/experience. You might have no problem successfully navigating that code for which you've already built a complete menta…
> objectively worse That's an opinion. There's nothing objective about the assertion that many small files are inherently more secure. However, that many small files and one large file have equivalent power, can express all the same programs, and can be equally secure or insecure... those actually are all objective facts.
Earlier quoted context omitted.
> objectively worse That's an opinion. There's nothing objective about the assertion that many small files are inherently more secure. However, that many small files and one large file have equivalent power, can express all the same programs, and can be equally secure or insecure... those actually are all objective facts.
I didn't say it was objectively more secure. Obviously it's possible to have code that is of poor quality/maintainability but still happens to be more secure than its alternatives. Maintaining good code quality is not a magic bullet that prevents all bugs.
It's popular to use "objectively" for "clearly" and I've been guilty of this myself, but let's try to reserve the term for actual matters of fact, lest it lose any meaning.
Earlier quoted context omitted.
I didn't say it was objectively more secure. Obviously it's possible to have code that is of poor quality/maintainability but still happens to be more secure than its alternatives. Maintaining good code quality is not a magic bullet that prevents all bugs.
Then replace secure with "maintainable" or "high quality". It's still a subjective opinion, unless you can prove that large files are inherently less maintainable or lower quality (which you can't, because all the arguments here are subjective and, like almost everything in software development, these opinions are driven by fashion rather than any evidence). It's popular to use "objectively" for "clearly" and I've be…
Personally I prefer smaller files, but that's only because of compile times. I started my career with punch cards, so I know what slow compile times look like. For a long time they seemed to be getting ever shorter, until I switched to a "modern C++" project. Now compile times are not quite back to the punch-card days, but back to maybe late 90s, and breaking stuff up into smaller files helps.
Earlier quoted context omitted.
Some of the points you raise are matters of style (I have files that are 10k lines long and think they are better that way; also I don't think unit tests are as useful as claimed), but yeah, when you have 600 files and 11MB of code to do something that is supposed to be simple and also is security-critical ... you have a big problem.
What a coincidence. I watched your video on Preventing the Collapse of Civilization just yesterday. (Mostly agree with things said there, with the exception of the part about Smalltalk. Ironically, the video was recommended to me in a Smalltalk chat channel.) Seems relevant. >Some of the points you raise are matters of style (I have files that are 10k lines long and think they are better that way It's true that line…