One of the tenets of the "Extreme Programming" people back around 2000 was "no comments -- the variable and function names should make the code self-explanatory"
I would certainly hope that anyone who calls themselves a C programmer would understand a very common idiom such as Bellard's ...Code: [Select]while (*p && *p++ != '\n')
... at a glance.
continue;
/* Skip to next line, but stopping at end of string. */
while (*p && *p++ != '\n')
continue /* or Nothing */ ;
See how your mind takes a different approach when seeing both the code and the comment, compared to seeing only the code?I've actually worked at a place that [...] had the rule "No comments except possibly one before a function explaining the purpose of the function".
Linux is too bloated
Its binaries are rather large, compared to other projects with similar features.
The problem is, whenever you see code like that that relies on side effects like post-increment after the test
Linux is too bloatedYes, but it has nothing to do with monolithic/microkernel architecture differences, and everything to do with featuritis.
As others have mentioned, a microkernel (with the same range of features supported) would probably be even larger.
The problem is, whenever you see code like that that relies on side effects like post-increment after the test
indeed, *p++ is banned by avionics rule #210
The problem is, whenever you see code like that that relies on side effects like post-increment after the test
indeed, *p++ is banned by avionics rule #210
Banning it altogether may be a bit much, but it is sound. '*p++' is pretty idiomatic and rather clear in itself; the main problem I see and we talked about earlier is using it inside a condition.
IMO, the real slippery and unreadable thing here is to use conditions with side-effects, and doing this should be clearly completely banned.
Single statements like 'var = *p++;' or '*p++ = var;' are OK IMO. 'if (*p++ != 0)' is NOT IMO. 'if (*p++)' is even worse, as IMO a condition should clearly be made a condition instead of taking shortcuts. The latter would be acceptable (without the '++') if '*p' is a boolean, but only in this case.
And that said, banning '*p++' in any situation would be fine with me. I wouldn't miss it much.
(We have to remember the old days when C compilers were not optimizing anything much and constructs such as '*p++' would directly map to a post-increment instruction on CPUs supporting this addressing mode, thus more efficient. Of course, it may have been the case a long time ago, but it's been pretty irrelevant for probably 3 decades, as this is very basic optimization.)
*p++ is pretty idiomatic and rather clear in itself
nope, the whole pointers arithmetic is also banned, except for seniors engineers, who are a super special case and only involved in critical code.
The only thing that exceeds the number of programming languages is the number of opinions about style. All completely correct of course. With measurable data to support the opinion.
Linux is too bloatedYes, but it has nothing to do with monolithic/microkernel architecture differences, and everything to do with featuritis.It has to do with *how* you debug the kernel!
The problem is, whenever you see code like that that relies on side effects like post-increment after the test
indeed, *p++ is banned by avionics rule #210
Which just goes to show that experiment design is as poorly understood on the software side of engineering as it is on the hardware side.
Which just goes to show that experiment design is as poorly understood on the software side of engineering as it is on the hardware side.I'd claim the opposite: we're so good at experiment design, we intuitively design the tests to support our preconceptions.
*p++ is pretty idiomatic and rather clear in itselfnope, the whole pointers arithmetic is also banned, except for seniors engineers, who are a super special case and only involved in critical code.
it was demonstrated it caused too many troubles with too many people and equipment; *p++ can make the ICE confused by the pointer arithmetic, as well as humans, and even the artificial intelligence of Stood is usually confused when it sees a *p++ inside a conditional branch during a dynamic coverage.
Which benefit? Well, we have an aspirin distributor on each floor, it's located in the Infirmary room, but it's somehow just next to the beverage and coffee distributor. Aspirins are a synthetic compound used medicinally to relieve mild or chronic pain and to reduce fever and inflammation. In our case, it was used to reduce the headache indirectly caused by the incompatibility between the C language's feature and our ICEs and AI.
After banning *p++, QA guys noticed the number of taken aspirins got reduced, as well as the number of coffee consumed at the beverage and coffee distributor room, and they deduced that by banning that C feature they substantially improved the efficiency and the health of the whole group
Sure, the inept and incompetence were catered too and this lowered their stress.
There were some architectures where ++/-- were supported by specific inc/dec instructions.
QuoteThere were some architectures where ++/-- were supported by specific inc/dec instructions.Umm. By the addressing modes available on nearly ALL instructions, on some CPUs.Notably the PDP/11, which supported pre-decrement and post-increment of a memory index register on nearly all of the instructions (and which had some influence on the design of C!).
yup, the PowerPC has autoincremented index opcodes, but the ICE doesn't like this too much, for *a lot* of reasons, and, worse still, people can do a mess with the GreenHills C compiler.
QuoteThere were some architectures where ++/-- were supported by specific inc/dec instructions.Umm. By the addressing modes available on nearly ALL instructions, on some CPUs.Notably the PDP/11, which supported pre-decrement and post-increment of a memory index register on nearly all of the instructions (and which had some influence on the design of C!).
And everything that copied or claimed to copy the PDP/11 instruction set; surviving is MSP430. ARM has this too, I guess (some versions of ARM, anyway.) (But not X86, MIPS, or RISC-V? (results of a quick check; I may not be up to date!))
addi rD,rD,-4
sub rS1,rS1,rD
sub rS2,rS2,rD
loop:
lw rA, (rS1, rD)
lw rB, (rS2, rD)
add rC,rA,rB
sww rC, 4(rD) ; mem <- rC, rD <- rD+4
blt rD,rLimit,loop
loop:
lw rA, 0(rS1)
lw rB, 0(rS2)
add rC,rA,rB
sww rC, 0(rD)
addi rD,rD,4
addi rS1,rS1,4
addi rS2,rS2,4
blt rD,rLimit,loop
Why are you using C at all in those critical projects?
in today's world we want everyone to pass the test without putting any work in.