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:	Mon, 25 Feb 2008 22:56:18 +0100
From:	Richard Knutsson <ricknu-0@...dent.ltu.se>
To:	Krzysztof Halasa <khc@...waw.pl>
CC:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: Tabs, spaces, indent and 80 character lines

Krzysztof Halasa wrote:
> Richard Knutsson <ricknu-0@...dent.ltu.se> writes:
>
>   
>>> I guess we could use tabs only at the line start, for indentation
>>> only. Rather hard to implement, most text editors can't do that yet.
>>>   
>>>       
>> You mean for split lines?
>>     
>
> Syntactic indentation vs alignment (including comments after
> non-blank, values for struct initialization etc, split lines too).
>
>   
'alignment', that's the word, thanks!
>> Hopefully there won't be that many, so there
>> is just to delete the tabs it added and replace it with spaces.
>>     
>
> Actually tabs "should" be used for indentation at start of the
> line, then spaces. "Ideally" :-)
>
> I.e., something like
> <TAB>	if (cond && (cond2 ||
> <TAB>	_____________cond3))
> <TAB>	<TAB>	do_something();
>
> Underline = space.
>
> Perhaps some day...
>
>   
>> Exactly! But then we can remove the "we use 8 wide tabs in the kernel"
>> in CodeStyle.
>>     
>
> I'm not sure it's practically possible now.
>   
Well, can always patch CodeStyle and checkpatch.pl and then see what the 
rest thinks.

Think checkpatch is fairly easy to "fix". It seems to have all the lines 
in an array so there is only a need to check the indent-depth of the 
line above and see if the current is the same with only spaces afterwards.

The idea was to reply with a patch, but it is bit late now.
>   
>>> Unpacked sources will be much bigger with not tabs, sure.
>>>   
>>>       
>> Without no tabs at all, you mean?
>>     
>
> With spaces in place of all tabs.
>
> All tabs converted to spaces = 20% more?
> "Alignment" tabs converted to spaces? How cares how much more would it
> take if it's the correct thing. Except that it's not very practical at
> this point.
>   
Would guess more...
The reason I reacted were because checkpatch.pl complained about a:
<tab><tab>foo(int a,
<tab><tab>____int b)
with the "use tabs not spaces". There is little point in patching this 
stuff but lets not make it worse (IMHO).

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