linux-ext4 - Re: [PATCH] ext2/e2fsprogs: fix cppcheck warnings

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 13 Aug 2018 14:50:32 +0000
From:   ykp@...tonmail.ch
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        Jaco Kroon <jaco@....co.za>
Subject: Re: [PATCH] ext2/e2fsprogs: fix cppcheck warnings

Thank you for pointing places where some job can be done.
I'll definitely check it and do my best to clean it up.

> Is there something specific you are interested in working on?

My original goal was to find out how fsck works, check if there
is a standard API for all set of fsck.* utilities and as a result
write a new one for fuse.cryfs filesystem.

Regards,
Vlad

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On August 13, 2018 4:37 PM, Theodore Y. Ts'o <tytso@....edu> wrote:

> On Mon, Aug 13, 2018 at 08:50:52AM +0000, ykp@...tonmail.ch wrote:
>
> > > So.... why?
> >
> > There is no great reason behind. I believe that evidently buggy code
> > needs to be fixed (or removed).
> > Yeah, cppcheck is not the best tool. In this case it was a way for me
> > to get along with both: e2fsprogs (I need a starting point to explore
> > the code) and cppcheck. I'm not going to run this static analysis
> > tool on a regular basis, treat it as a learning step.
>
> If you want to do code cleanup, it's better to either look for Clang
> warnings or gcc-wall warnings. The first can be done via "CC=clang
> configure". The second can be done via running "make gcc-wall" in a
> particular build directory. After you fix gcc-wall issues, you can
> run "make gcc-wall-new" to only run gcc -Wall on the modified files.
>
> You can run the test_script in the tests directory with the --valgrind
> or --valgrind-leakcheck.
>
> In some cases we've deliberately neelded not fixed a warning when it's
> not worth it. Long-term maintainability and code readability is
> important.
>
> One file where a lot of cleanup can be needed --- not just blindly
> cleaning up gcc -Wall or clang warnings, but rather restructing and
> general code cleanup to make the code cleaner and consistent with
> general e2fsprogs code quality and style --- is misc/e4defrag.c.
> There is some interest by Jaco to add new featuers on e4defrag, so if
> that is something you are interested in doing somme cleanup work on,
> we'll need to do some air traffic control to avoid change conflicts.
>
> Is there something specific you are interested in working on?
> Finally, one potential issue. Since you are working under an
> encrypted channel and you aren't specifying your name, I assume you
> are concerned about preserving your anonymity. One of the problems is
> that if you are making code contributions, I need to know that who you
> are. It doesn't have to be public --- you can let me know in private
> --- but I do need to know your identity. There is precedence for this
> --- "George Spellvin" is an occasional contributor to the Linux
> kernel, but Linus Torvalds know who he is, and that's been considered
> sufficient. Please see the description of the Developers
> Certification of Origin (e.g., the "Signed-off-by" header) for the
> background about what it is that we require code contributors to agree
> when they contribute code.
>
> Cheers,
>
> - Ted