lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 17 Dec 2009 08:21:10 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
cc:	Américo Wang <xiyou.wangcong@...il.com>,
	Mikulas Patocka <mpatocka@...hat.com>,
	linux-kernel@...r.kernel.org, Alasdair G Kergon <agk@...hat.com>,
	dm-devel@...hat.com
Subject: Re: [PATCH] Drop 80-character limit in checkpatch.pl



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". 

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ