Re: [RFC] [WIP] incorporate picotcp into barebox: a small demo

[Daniele Lacamera <daniele.lacamera@tass.be>]

Antony, regarding your comments on picotcp "cleaning", could you
please elaborate a bit more, taking into account my comments below?

On Mon, May 26, 2014 at 2:09 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote:
> Picotcp need some work for cleaning. I think that on average barebox code is more clean
> that picotcp code (there are too many #ifdefs, some compiler warnings, formatting),
> but IMHO it is not very difficult to make it cleaner.
>

- The amount of #ifdefs in the code is due to the size optimizations.
Types are left out when modules are disabled, would be much more
difficult to achieve the same code size, e.g. on a 8-bit machine, if
we used empty proxies instead, like for instance Linux does. Keep in
mind that saving a few bytes is the key for some of our projects, so I
would accept no modification for the sack of aesthetic if it would
impact on code size. Our quality processes ensure that the branching
is kept under control, and our continuous integration takes into
account enabling and disabling the modules.

- compiler warnings: AFAIK, our code is warning free on gcc, it might
be that a specific platform config could trigger some. We are
interested about your experience, please share your findings, but
please do not report -Wshadow warnings obtained with broken gcc (<=
4.6).
Our default set of warning flags:  -Wall -Wdeclaration-after-statement
-W -Wextra -Wshadow -Wcast-qual -Wwrite-strings
-Wmissing-field-initializers -Wconversion -Wcast-align

- formatting: Could it be that you checked an intermediate
masterbranch version? We run uncrustify periodically on the code, and
our formatting is consistent with our own rules.

Thanks


/d

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox