"Those are fundamental things that should be second-nature to you if you claim to really know C"
That's a bogus argument. There's an easy way to write code that's readable and maintainable by mixed teams and then there's this macho way of showing off to no particular advantage.
- just remember that this is a strcpy, as shown in K&R:
while(dst++ = src++)
;
Or -- just don't. Just write code that doesn't rely on every reader to mentally clear through a dense thicket of precedence and side-effects to understand your strcpy and get your job done in a pragmatic fashion with 4 lines of easily understood C code instead of 1 line that makes your heart glow with momentary pride.
The problem here is that the bug is not in the "dense" part - it's more likely that whoever wrote that code thought memset was always used to set blocks of memory to 0, and as for why it wasn't discovered sooner: it wasn't being used for anything else! Someone with that misunderstanding could've just as well have written what you consider more "readable" code, but with the same bug:
You're right the bug is not in the dense part, but adjacent to it. My argument was that the extra cognitive overhead of digesting this complexity leads to the original authors and reviewers of the code to miss other obvious bugs.
One could reasonable speculate if a code-reviewer had sent the original code back to be written in a readable fashion, the actual bug in the code would have been caught too.
As far as I'm concerned, that while expression is simpler than any possible three-statement for loop could be. Similarly, as long as the line is short, I have to dedicate less thought to tracking a single-line bracketless loop than a multi-line bracketed loop. (But don't use multiple lines without brackets, that makes it too hard to find the start and end and slows me down.)
I can see your point about *p++ being a speed bump, but overall this version seems less complex to me.
Sorry our definitions of what constitutes a "professional" are entirely different. The best teams I've worked in take great care to avoid needless complexity in code. Readability and maintainability take precedence over everything else... (even performance unless proven otherwise by measurement).
Given the kinds of projects I've been part of are already swarming with (externally imposed) system complexity to begin with, an attitude of "I write dense code since I'm a professional" won't get anyone very far in such teams.
I'm sorry if that seems dense to you. That's pretty much beginner C stuff; after years of writing it, its absolutely transparent to an experienced programmer. I'm astonished at the vitriol; every language takes some learning whether it be lambdas or annotations or declarations or whatever; if it seems opaque to you, perhaps some reading is in order.
And yet we started off discussing a serious bug in libc discovered in exactly that kind of code. That's the libc in Android!! My argument is that the extra cognitive overhead of digesting needless complexity leads to the original authors and reviewers of the code to miss other obvious bugs.
I'm astonished at the vitriol
I'm sorry if my straightforward and respectful response to your dismissive and patronizing remarks sounds vitriolic to you.
Because somebody is writing the libc code says nothing about their skill; just the opposite because who wants to be in charge of reimplementing tired old library routines? The new guy I would imagine.
This bug is simply a failure to test. Where was the trivial automated unit test for this library routine? Never written I imagine.
Reminds me of another buggy library I had to work with - the Linux c runtime. I was porting to a risc processor oh ten years ago. Something was wrong with the memcpy routine. So I wrote a unit test. A very thorough unit test. Found 12(!) bugs before I was through.
Test was: copy from aligned source + (0..128) to aligned destination + (0..128) length (0..128). Simple triple loop. Anybody could have written it. Nobody ever had.
This is not a C problem, or an Android problem. Its an industry problem. Intel shipped a Pentium processor once upon a time that couldn't divide by 10.
Again, that's normal C code. Maybe you don't like the language; maybe you don't want to learn it. But its absolutely common and you won't get very far without mastering that stuff.
Would we criticize assembler because its full of confusing registers and stuff? Sure go ahead; but it sounds silly.
That's a bogus argument. There's an easy way to write code that's readable and maintainable by mixed teams and then there's this macho way of showing off to no particular advantage.
- just remember that this is a strcpy, as shown in K&R: while(dst++ = src++) ;
Or -- just don't. Just write code that doesn't rely on every reader to mentally clear through a dense thicket of precedence and side-effects to understand your strcpy and get your job done in a pragmatic fashion with 4 lines of easily understood C code instead of 1 line that makes your heart glow with momentary pride.