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-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1007131644180.1500@localhost.localdomain>
Date:	Tue, 13 Jul 2010 17:00:21 +0300 (EEST)
From:	Dimitrios Apostolou <jimis@....net>
To:	linux-kernel@...r.kernel.org
cc:	Dan Nicolaescu <dann@....org>
Subject: emacs and "linux" coding style

Hello list,

according to Documentation/CodingStyle the "linux" style of emacs is 
broken because it uses tabs+spaces when continuing the argument list of a 
function on a new line. So I reported that as a bug to bug-gnu-emacs 
(bug#6617).

However it's not clear if this is a bug of emacs or an inconsistency of 
the linux kernel coding style. I can't find where exactly the usage *only* 
of tabs is mandated, see for example the following quote:


> Statements longer than 80 columns will be broken into sensible
> chunks. Descendants are always substantially shorter than the parent
> and are placed substantially to the right. The same applies to
> function headers with a long argument list. Long strings are as well
> broken into shorter strings. The only exception to this is where
> exceeding 80 columns significantly increases readability and does not
> hide information.


Tabs are not mentioned anywhere, besides the specific part about emacs 
which is so ironic that no emacs dev can read it fully. Moreover there are 
many parts in the kernel that are aligned using both tabs and spaces. 
Random example in the linux-2.6.34.1 kernel: kernel/sched.c


static void update_group_shares_cpu(struct task_group *tg, int cpu,
                                     unsigned long sd_shares,
                                     unsigned long sd_rq_weight,
                                     unsigned long *usd_rq_weight)
{


So what do you think? Should the current emacs "linux" style be fixed, or 
are spaces allowed?


Thanks,
Dimitris

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