On Thu, Dec 17, 2009 at 9:51 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Thu, 17 Dec 2009, Bartlomiej Zolnierkiewicz wrote: >> >> Well, it could have been done in the other way: >> >> - ret = sscanf (buf, "0x%lx - 0x%lx", &start_addr, &end_addr); >> + ret = sscanf(buf, "0x%lx - 0x%lx", >> + &start_addr, &end_addr); >> >> Just an example that the limit itself is usually not a problem >> but its literal interpretation is.. > > What? Your version is no better. > > In the above case it doesn't matter, but I've had grep's that fail due to > people splitting the actual string etc, which just drives me wild. We > fixed that to allow checkpatch to skip those warnings, but the fact is, > the fundamnetal problem has always been the "80 character" part. > > I don't think any kernel developers use a vt100 any more. And even if they > do, I bet they curse the "24 lines" more than they curse the occasional > 80+ character lines. > > I'd be ok with changing the warning to 132 characters, which is another > perfectly fine historical limit. Or we can split the difference, and say > "ok, 106 characters is too much". I don't care. But 80 characters is > causing too many idiotic changes. > > There are way worse problems in many patches than long lines. Too complex > expressions. Too deep indentation. Pure crap code. People seem to get way > too hung up on ".. but at least it passes checkpatch". > I truely agree on this.It will better if we can change the warning for 100+ as suggested.This cleans the code alot infact. -Ram -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
