Hi Kees,
Like Ludwig wrote, there are some places which haven't followed the coding
conventions because the CC weren't as clear before as they are now with
regards to this. Since RIOT is relying on its community for code
contributions, these kinds of clean ups may take a long time after the
documentation has been updated until someone decides to fix them.

The SPI periph driver is going through some rework, see
https://github.com/RIOT-OS/RIOT/pull/4780 and
https://github.com/RIOT-OS/RIOT/issues/4758, but it has not yet been merged
because of various other things getting in the way.

Best regards,
Joakimr

On Mon, Jul 4, 2016 at 7:23 AM, Ludwig Knüpfer <ludwig.knuep...@fu-berlin.de
> wrote:

> Hi Kees,
>
> Unless there is a good reason to deviate from this guideline all
> violations should be corrected. This particular rule was added relatively
> recently, so it would not surprise me if not all occurrences in RIOT have
> been adapted yet.
>
> Cheers,
> Ludwig
>
> Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker <k...@sodaq.com>:
> >Hi,
> >
> >The Coding Convention is clear about it.
> >
> >"Guidelines for pointer types (as long as it is reasonable):
> >
> >  * use |char *| for strings and only for strings
> > * use |uint8_t[]| as type for arbitrary byte buffers, but use |void *|
> >    to pass them around. |uint8_t[]| because we're dealing with bytes
> >    and not characters, |void *| to avoid unnecessary casting shall the
> >    need arise to have their content to have a certain type
> >  * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
> >    addresses, where it avoids unnecessary temporary variable
> >  * use |void *| for generic typing"
> >
> >
> >In the SPI driver however the transfer functions use char * parameters,
> >
> >but SPI is usually dealing with binary
> >information (bytes), not strings. This leads to unnecessary casts in
> >other parts of the code. (E.g. nvram_spi).
> >
> >What is our policy about this? Are we going to correct this at some
> >point? Is it too late already (I hope not)?
>
> _______________________________________________
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Reply via email to