linux-kernel - Re: [PATCH] drivers: Conversions from kmalloc+memset to k(z|c)alloc.

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, 24 Jul 2006 02:10:46 +0200 (CEST)
From:	Tomasz Kłoczko <kloczek@...y.mif.pg.gda.pl>
To:	Michael Buesch <mb@...sch.de>
cc:	linux-kernel@...r.kernel.org, Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [PATCH] drivers: Conversions from kmalloc+memset to k(z|c)alloc.

On Sun, 23 Jul 2006, Michael Buesch wrote:
[..]
> Yeah, please stop it.
> Did you actually _look_ at what indent does to code sometimes?
> It sometimes (often?) renders perfectly readable code into a
> huge blob of crap.

Do you remember file names ?
I'm just review diff after using indent with Lindent args and only in few
places I saw something badly looking:
- badly formated __asm__ () content
- in case some functions with very long function names worser looling
   function header,
- struct with filled field using multicolumt (why not use single col ?)

IMO curent issue isn't "indent produces (generaly) bad output" but "in 
some very limited (compare to all amout of code) cases it produces 
something looking bad".
In all other/most of cases (probably ~99%) Lindetd can be used 
.. but for NOW GENERALY IT IS NOT NOT USED.

> Face reality. The linux kernel is following the general codingstyle
> very well already. I don't think there is need to improve the current
> codebase for non-existent codingstyle issues. And we already review
> new code for codingstyle issues, so the codebase remains clean.

Sorry but it is not true. There is no single coding style. Now in probably 
compareble amout of points is used constructions like:

1) top of the function:

static inline void *
find_pa(unsigned long *vptb, void *ptr)

or

static inline void *find_pa(unsigned long *vptb, void *ptr)

(Lindent produces second variant)

2) type conversion:

        return (void *) result;
or
        return (void*)result;
or
        return (void *)result;

(Lindent produces last)

3) using tab or not (Lindent produces code with tabs)

4) sometimes functions argumeta are formated in sigle colum but sometimes
    not:

                 printk("%s   Module Type: 0x%x - Unit ID 0x%x - "
                        "Condition 0x%x\n",
                        err_print_prefix,
                        env->module_type,
                        env->unit_id,
                        env->condition);
or
                 printk("%s   Module Type: 0x%x - Unit ID 0x%x - "
                        "Condition 0x%x\n",
                        env->module_type, env->unit_id, env->condition);

5) remove trailing spaces or not (indent removes trailing spaces)

and probably much, much more small details like this.

> Look at other projects with horrible codingstyle problems
> and suggest solutions to their _real_ issues. *cough*kde*cough*

Sorry but in this case it is simple chicken and egg problem. First you 
must define "coding style" details and after this you 
can start work on tool for indenting all source code.

Now I know why Linux code NEVER was autoformated using some tool. Cause is
VERY simple: because THERE IS NO complet coding style definition for 
Linux tree.

Current Documentation/CodingStyle contains only *very* limited neccessary 
for finish this details.
There is not general rule like "if it produces correctly looking output 
use Lindet" so current Linux coding style is "free style" .. nothing more.

Add general advice "try use Lindent" will allow start discuss on some 
never defined coding style details. Probaly it will als show some bad 
coded fregmets (for exxample when somen uses very long identifiers for 
variables or function names and it will badly look on 80 colums).
Withouty this any time when "coding style" will back it can produce next 
flame theread.

kloczek
PS. In case coding style Linus is right "Documentations/specyfications is 
close to useless" because usability of Documentation/CodingStyle is realy 
cloase to useless but .. in *this* case ducumetation isn't guilty.
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@...y.mif.pg.gda.pl*