Let me talk clear: in the portion of Zephyr currently checked we have more than 18K violations of what I think is one of the most valuable rule of BARR C that asks that any non obviously

After taking a look at https://github.com/zephyrproject-rtos/zephyr/pull/41227 I fully agree with Nicolas and honestly I hate this more than I could have possibly imagined before. The code is now

Let resume state after commit with the points still to be decided, so we can be more specific and finalize: - 0 is success, non-zero is error: the comunity agrees to change to have - Z_OOPS takes an

Wow! OK... I see that this fu^H^Hmixed-up convention already exists in the tree today. You simply followed that precedent. [...] * @return False on success, True on failure */ #define

I think you have noted that at least another member has presented some objections. Which strategies the comunity have adopted in similar cases to obtain a fast convergence and to avoid

I think <sys/util.h> would be a good place. Please make it into a fetchable branch. That'd make my reviewing easier. Nicolas

Cancelled: Zephyr: Power Management Sync This event has been cancelled. When: Thursday, December 30, 2021 11:00am to 12:00pm (UTC-08:00) America/Los Angeles Where: Microsoft Teams Organizer:

Cancelled: Zephyr: Power Management Sync This event has been cancelled. When: Thursday, December 23, 2021 11:00am to 12:00pm (UTC-08:00) America/Los Angeles Where: Microsoft Teams Organizer:

Cancelled: Zephyr: Power Management Sync This event has been cancelled. When: Thursday, December 16, 2021 11:00am to 12:00pm (UTC-08:00) America/Los Angeles Where: Microsoft Teams Organizer:

Reminder: Zephyr: Power Management Sync When: 12/16/2021 11:00am to 12:00pm (UTC-08:00) America/Los Angeles Where: Microsoft Teams Organizer: devel@... An RSVP is requested. Click here to

Hi Abramo, I think Nicolas makes some good points here. Zephyr code is too different from Linux style for my liking, e.g. the strange {} around single-line statements. Things like 'if (rc != 0)'

Reminder: Zephyr Project: Dev Meeting When: 12/16/2021 8:00am to 9:00am (UTC-08:00) America/Los Angeles Where: Microsoft Teams Meeting Organizer: devel@... An RSVP is requested. Click here

Unless we find a good place for this macro I'd be forced to leave double cast. If it is preferred I can add a line of documentation before each occurence. I'd like very much you take a look

Agenda for this week's Dev-Review meeting: Add iomux rt driver - https://github.com/zephyrproject-rtos/zephyr/pull/40880 shields: add generic shield to use CDC ACM UART as backend -

Absolutely! This is a great example of papering over what is most likely a flaw in the code. Instead of questioning the fundamental of such non-preserving conversion, the added cast gives the

Are you really arguing that a commented explicit cast (for non obviously value-preserving conversion) is worse than an implicit cast? Are you taking in account that although you can write tests for

I appreciate your points, and similarly for a few others before yours, but I think they are missing the point. No one is against virtue. Everybody wants the code base to be more consistent, more

Hi, I've written this email two days ago and somehow it never left my outbox so I'm re-sending it because I think it is still relevant. We should keep this discussion as much technical as possible.

A few points from my side (probably nothing that has not been already said) MISRA mostly tries to avoid undefined behavior derived issues. Other languages such as Rust have done a better job on this

Olof, Point taken, will start posting agenda the day before. Anas From: devel@... <devel@...> on behalf of Olof Johansson <olof@...> Date: Wednesday, December 15, 2021 at 2:14 AM To: Hibberd,