In my opinion, is using net_if_get_default more appropriate than using net_if_get_first_by_type(&NET_L2_GET_NAME(DUMMY)) in tests/net/dhcpv4/src/main.c:434? Reason: If using the

Hi I have an issue in doing networking using qemu arc I tried SLIP networking using civetweb/http_server Same can work with QEMU_CORTEX_A9 and QEMU_X86 But cannot work with QEMU_ARC_EM

I agree. I don't know why that test and a couple others were created. This is demonstrably extremely brittle and untrustworthy. Nicolas

I confirm that this is ugly (and dangerous) as hell and I really hope that this is not taken for granted in any part of Zephyr code. Once said that it is not surprising that compiler don't have

volatile long long_max = LONG_MAX; volatile long long_one = 1L; void test_limits(void) { zassert_true((long_max + long_one == LONG_MIN), NULL); } It is an undefined behavior per one of your

No, I simply keep stating the obvious: you can test a finite number of instances but not all of them and a compiler is free to bite you where you don't expect that (just like you are free to infringe

For the n-th time I'll repeat this: it can be tested. In this particular case it is extensively tested by the CI infrastructure. In the unlikely event one compiler implementation decides to

The law enforcement analogy is completely misdriven: our case is not related to your freedom to do something (I assure you that you are perfectly free to introduce undefined behaviors in your

No. I disagree to such dogmatic stance. But let's start with a few facts of life. Did you know it is illegal to change a light bulb yourself if you live in Victoria, Australia? Did you know that

As long as there is still an undefined behavior in the code, I'd like you resign yourself to the fact that this cannot be accepted. Let me try another time to explain, I hope to not make you bored

Is that the case? If so I missed it. One thing that could help you get proper reviews is to split your PR in smaller chunks. Your original change is way too big. Maybe that particular part was OK,

Well... I took this as a challenge and attempted it. And it didn't work satisfactorily. The problem is that the buf pointer accomplishes two roles: it serves as a buffer offset as well as a memory

IOW you are proposing to do exactly what I presented the first time, but inverting the boolean logic from original true for failure and false for success to false for failure and true for success. It

I'm truly sad saying that, but if you keep stating that to write code that has undefined behavior for C standard and such behavior is not a documented compiler extensions is a sane thing to do, I find

It should, especially if the calling code already uses != 0 or == 0. Success with > 0 is not that frequent. But that's for functions that perform a substantial action. It would be overkill for

18K violations and still it works. There are so many of those occurrences that move back and forth between int and char. Especially in string formatting for numerical value. And in those cases, the

+1 on this response as it should be the first thing we attempt to do! In my past, my first instinct when getting these types of static analysis issues was to look at the underlying code to determine

If I may add my 2 cents here... The code looks ugly, but isn't it because the rules were violate in first place and here is fastest (not prettiest) way to make it compliant? Wouldn't it look good if

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