These warnings fix a class of warnings that I saw during CI checks for macOS sim builds. For example:
devif/devif_callback.c:111:49: warning: for loop has empty body [-Wempty-body]
prev = curr, curr = curr->nxtdev);
^
devif/devif_callback.c:111:49: note: put the semicolon on a separate line to silence this warning
I did not put the semi-colon on a separate line, but used braces.
Modified boards/z80/z180/p112/README.txt and boards/z80/z80/z80sim/README.txt:
IMPORTANT NOTE as of 2020-4-11: Support for CONFIG_CAN_PASS_STRUCTS was removed in NuttX-9.1. This was necessary to enforce some POSIX interface compliance but also means that ALL older SDCC versions will no long build with NuttX. I have been told that the newest SDCC compilers can indeed pass structure and union parameters and return values. If that is correct, then perhaps the newer SDCC compilers will be used. Otherwise, it will be necessary to use some other, more compliant compiler.
Run all files modified by PR 766 through nxstyle and fix any resulting complaints.
NOTE: Numerous "Mixed case identifier" errors in arch/arm/src/cxd56xx/cxd56_gnss.c were not fixed because this problem is of much larger scope than this file.
This commit resolves issue #620:
Remove CONFIG_CAN_PASS_STRUCTS #620
The configuration option CONFIG_CAN_PASS_STRUCTS was added many years ago to support an old version of the SDCC compiler. That compiler is currently used only with the Z80 and Z180 targets. The limitation of that old compiler was that it could not pass structures or unions as either inputs or outputs. For example:
#ifdef CONFIG_CAN_PASS_STRUCTS
struct mallinfo mallinfo(void);
#else
int mallinfo(FAR struct mallinfo *info);
#endif
And even leads to violation of a few POSIX interfaces like:
#ifdef CONFIG_CAN_PASS_STRUCTS
int sigqueue(int pid, int signo, union sigval value);
#else
int sigqueue(int pid, int signo, FAR void *sival_ptr);
#endif
This breaks the 1st INVIOLABLES rule:
Strict POSIX compliance
-----------------------
o Strict conformance to the portable standard OS interface as defined at
OpenGroup.org.
o A deeply embedded system requires some special support. Special
support must be minimized.
o The portable interface must never be compromised only for the sake of
expediency.
o Expediency or even improved performance are not justifications for
violation of the strict POSIX interface
Also, it appears that the current SDCC compilers have resolve this issue and so, perhaps, this is no longer a problem: z88dk/z88dk#1132
NOTE: This commit cannot pass the PR checks because it depends on matching changes to the apps/ directory.
Hello,
I am testing priority inversion feauture of Nuttx scheduler. I encounter with problem in tests.
Here is problem:
nxsched_readytorun_setpriority() function not works as expected when DEBUG_ASSERTION not enabled. Because sched_removereadytorun() and sched_addreadytorun() is not called in this case. These functions wrapped with DEBUGASSERT macro and with the effect of DEBUGASSERT macro, sched_removereadytorun() and sched_addreadytorun() not called when DEBUG_ASSERTION not enabled. Therefore priority inversion not works as expected.
Could you check this problem ? Is this a bug, if not what is the purpose of this code ?
Thanks,
Şükrü Bahadır Arslan
Call 'tools/testbuild.sh -e -Wno-cpp testlist' would pass "EXTRAFLAGS=-Wno-cpp"
to make command line. Then it could suppress the warnings with pre-processor
directive #warning in GCC.
Change-Id: I61e5f9b3774149f64bdd625677cc9aabaa2fea90
Signed-off-by: liuhaitao <liuhaitao@xiaomi.com>
So call 'make EXTRAFLAGS=-Wno-cpp' could suppress the warnings with pre-processor
directive #warning in GCC.
Change-Id: Iaa618238924c9969bf91db22117b39e6d2fc9bb6
Signed-off-by: liuhaitao <liuhaitao@xiaomi.com>
- inline functions within mpu.h converted to macros or moved to up_mpu.c
- mpu.h and up_mpu.c are now conditionally included in build via CONFIG_ARM_MPU
Chips affected by these changes
- imxrt
- kinetis
- lpc17xx
- lpc43xx
- lpc54xx
- sam34
- stm32
- stm32f7
- stm32h7
- stm32l4
- tiva
- xmc4
The same functionality could be implemented in the common place(netlink_recvfrom)
Change-Id: I8aedb29c4f0572f020ca5c0775f06c5e1e17ae4a
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
* boards/arm/stm32/nucleo-f429zi: Initial port to nucleo-f429zi board.
* boards/arm/stm32/nucleo-f429zi: Add two demo configs.
* Add the nucleo-f429zi to boards/Kconfig
boards/Kcondig: Fixed line alignment issue.
* boards/arm/stm32/nucleo-f429zi: Change the license header of all new files to an Apache 2.0 license.
* boards/arm/stm32/nucleo-f429zi: nxstyle fixed
and for future Apache releases.
- Rename the final tarball to add incubating and apache to their names
- Make the tool usuable from a development repo.
- Add a list of patterns(files and folders) to exclude and
a command line argument to pass aditional patterns.
- Add a command to run silently.
- If the build number was not provided let version.sh figure it out.
This commit fixes some long single line comments. This effort was primarily intended to verify the change to tools/nxstyle of PR #743 further. This took the files changed with 1501d284c3 and ran them through nxstyle again. The files in the commit previously passed the old nxstyle test with no complaints. The current nxstyle, on the other hand, reported 49 long single line comments. Each of those were verified and the file was updated. The nxstyle change appears completely reliable.
This resolves issue 718: nxstyle line width check was ignoring the line width check for single line comments.
This turned out to be an artifact in parsing. Usually when parsing character by character, the file character to be parsed was '/n'. Howefver, in the case of parsing single line comments, the final character was the NUL terminator. This means that the lenth check was not being performed in the case of single line comments.
NOTE: Currently, I have suppressed error reports for single line right-hand comments. My fear is that this will unmask more standard violations than we can cope with. It is easy to re-enable and perhaps we should do that in the future:
/* Check for long lines
*
* REVISIT: Long line checks suppressed on right hand comments
* for now. This just prevents a large number of difficult-to-
* fix complaints that we would have otherwise.
*/
if (m > g_maxline && !rhcomment) <-- remote the second condition
A mutex may be configured with rather exotic options such as recursive, unsafe, etc. The availability of these mutex options is controlled by configuation settings. When each option is enabled, additional fields are managed inside of the mutex structure.
pthread_cond_wait() and pthread_timed_wait() do the following atomically: (1) unlock the mutex, (2) wait for the condition, and (3) restore the mutex lock. When that lock is restored, pthread_cond_[timed]wait() must also restore the exact configuration of the mutex data structure if these "exotic" features are enabled.
Now that nxsem_wait_uninterruptible() returns an error when the thread is canceled, new logic is being executed. This revealed an existing error in pthread_cond_wait(). The nature of the error is as follows:
* pthread_cond_wait() must atomically (1) release the mutex, (2) wait on the condition, and (3) re-establish the mutex. Errors can occur on any of these steps. In this case the ECANCELED error was (very correctly) reported by nxsem_wait_uninterruptible().
* However, logic in step (3) had a bug; it re-acquired the mutex, but then a bug in existing logic cause the mutex to be improperly initialized. Essentially, the wrong error status value was being testing. This resulted in a nonsequitar and errors reported by the OS test.
This problem was found by apps/testing/ostest/pthread_cleanup.c
Resolution of Issue 619 will require multiple steps, this part of the first step in that resolution: Every call to nxsem_wait_uninterruptible() must handle the return value from nxsem_wait_uninterruptible properly. This commit is for all remaining drivers in the LC823450 architectures.
