PR per driver sounds good to me.
The required change in tcs37727 indeed involves a bit more. But I hope that
everyone agrees that you cannot change a const object into a non-const
object.
Take a look at the doxygen. The param[in] is misleading, the object will
be modified.
Ha, it even says so
A controversial idea is to change the implementation to C++ and make the
driver a proper class with inheritance and utilize polymorphism with
dynamic casts.
/Joakim
Den tor 27 dec. 2018 21:51 skrev Kees Bakker :
> On 27-12-18 13:54, Kaspar Schleiser wrote:
> > Hi,
> >
> > On 12/26/18 11:16 PM, K
On 27-12-18 13:54, Kaspar Schleiser wrote:
Hi,
On 12/26/18 11:16 PM, Kees Bakker wrote:
Suppose I make a Pull Request to eliminate casts, would that be picked up?
Always welcome! +1 on Joakim's hint to keep the PR's small.
Sure
void at86rf2xx_tx_exec(const at86rf2xx_t *dev)
{
netdev_t *
Hi,
On 12/26/18 11:16 PM, Kees Bakker wrote:
> Suppose I make a Pull Request to eliminate casts, would that be picked up?
Always welcome! +1 on Joakim's hint to keep the PR's small.
> void at86rf2xx_tx_exec(const at86rf2xx_t *dev)
> {
> netdev_t *netdev = (netdev_t *)dev;
What would be the
I agree with your arguments. Placing casts where they are not needed may
introduce errors in a future refactoring where a variable changes type.
If you want your changes merged as smoothly as possible you should open a
separate PR for each module you modify. It will make the review much
easier. Stu
Hey,
In general, I'm not happy with casts when they are not really needed.
A cast takes away an opportunity for the compiler to check things.
Sometimes a cast is there to get rid of "const". That's not good.
Sometimes a cast is there to get rid of "volatile". That's not good either.
Suppose I ma
