On Tue, 27 May 2014 19:26:14 +0200
Daniele Lacamera <daniele.lacamera@xxxxxxx> wrote:
> Antony, thank you very much for the comments and the bug reports on
> our github. See comments below.
>
> On Tue, May 27, 2014 at 4:04 PM, Antony Pavlov <antonynpavlov@xxxxxxxxx> wrote:
> > On Tue, 27 May 2014 11:46:29 +0200
> > Daniele Lacamera <daniele.lacamera@xxxxxxx> wrote:
> >
> >
> > linux kernel and barebox use not so much #ifdef's because they use
> > they use IS_ENABLED() macro with just the same result.
> [...]
> > so the code under IS_ENABLED() is always parsed by C compiler;
> > if there is an syntax error in this code then the compilation will be stopped.
>
> We will discuss this and see if it is applicable for PicoTCP. The
> macro you are suggesting is indeed not increasing code size, but our
> static checkers might be not so happy about all this preprocessor
> machinery.
>
> >
> > $ gcc --version
> > gcc (Debian 4.8.3-1) 4.8.3
> >
> > Here is my 'make -s' output for sandbox barebox:
> >
> [cut]
>
> Thank You!! This *IS* very helpful input. We are going to add more -W
> flags and quickly fix these warnings.
>
> > But in linux kernel, barebox, qemu and IMHO many other projects
> > there are:
> >
> > * CODING_STYLE documentation file;
> > * scripts/checkpatch.pl
> >
>
> All good points. Being a kernel developer myself, I know the
> checkpatch.pl approach, and indeed it is a good thing to distribute
> coding rules if you accept contributions. Except it will never apply
> to us, because:
>
> - We have our company internal coding style which we apply to all our
> projects and we don't feel the need to distribute externally (keep in
> mind that we never planned to accept external contributions). Instead,
> the repository contains the uncrustify configuration file, which is
> pretty much self-explanatory.
> - A few of us are checking every single commit, and running uncrustify
> every now and then. We are comfortable with this approach
Be very carefull with this approach.
It looks like uncrustify changes not only whitespaces and newline symbols!
I suppose that it can change code logic!
E.g. please see this commit
commit 81f52a4ad8fd31edcedd7c91945c801899153d36
Author: Daniele Lacamera <daniele.lacamera@xxxxxxx>
Date: Wed Mar 12 12:29:21 2014 +0100
Enforced coding style
Here is a notable fragment
--- a/modules/pico_mm.c
+++ b/modules/pico_mm.c
@@ -75,80 +79,80 @@ typedef union block_internals block_internals;
<---------------------------------------------------------------------->
- +------------<------------+----------<-----------+
- | ^ ^
+ +------------<------------+----------<-----------+
+ | ^ ^
v | |
- +---------+------------+--+----+---------------+-+-----+---------------+
- | | | | | | |
- | pico_ | | pico_ | | pico_ | |
- | mem_ | ...HEAP... | mem_ | slab | mem_ | slab |
- | page | | block | | block | |
- | | | | | | |
- +---------+------------+-------+-----+---------+-------+----------+----+
+ |+---------+------------+--+----+---------------+-+-----+---------------+
+ | | | | | | |
+ | pico_ | | pico_ | | pico_ | |
+ | mem_ | ...HEAP... | mem_ | slab | mem_ | slab |
+ | page | | block | | block | |
+ | | | | | | |
+ |+---------+------------+-------+-----+---------+-------+----------+----+
The number of '|' symbols is changed! After this commit you have at least
two additional '|' symbols. TIP: look at the start of the last line of the fragment.
> - Linux coding rules are generally recognized as possibly not the best
> in the world. I especially dislike tabs.
> - commit hooks are tedious
>
> I am afraid we are not going to change our formatting style or policy,
> but thanks anyway for the suggestions!
--
Best regards,
Antony Pavlov
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
