mirror of
https://github.com/zephyrproject-rtos/zephyr
synced 2025-08-18 21:55:55 +00:00
Each GCC target backend is at liberty to define its own SIZE_TYPE. GCC uses this for various purposes, not lease it drives the machinery that spits out format specifier diagnostics when format specifiers are applied to objects with inappropriate type. GCC exposes the current definition of SIZE_TYPE via the preprocessor symbol __SIZE_TYPE__. The GCC build processes also generates various standard library header files that directyle expose stanard types in a form consistent with the current configuration of GCC. Conventionally standard library build processes (for glibc and newlib) pick up the header files generated by the GCC build. In the minimal libc we have no such build process, we don't pick up the header files that the GCC build process generated. Instead we define our own alternative header files and align them with GCC manually. The current definition of ssize_t in minimal libc is out of step with GCC which means that any use of the %z[du] format modifier will issue a diagnostic. We replace the open coded architecture detection in minimal libc and use GCCs __SIZE_TYPE__ directly. Change-Id: I63b5e17bee4f4ab83d49e492e58efd3bafe76807 Signed-off-by: Marcus Shawcroft <marcus.shawcroft@arm.com> tests: fs: Fix printf warning when using newlib Current code uses %ld format specifier to print data of type ssize_t. This causes type warnings when built with newlib. The correct format specifier to be used for ssize_t is %zd. Change-Id: I02a3c628e3d6e8a36a09cd694220406d8faf1730 Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com> |
||
---|---|---|
.. | ||
src | ||
Makefile | ||
prj.conf | ||
README.txt | ||
testcase.ini |
Title: Zephyr File System Demo Description: Demonstrates basic file and dir operations using the Zephyr file system. -------------------------------------------------------------------------------- Building and Running Project: The demo will run on Arduino 101 and will use the on-board SPI flash. make BOARD=arduino_101 -------------------------------------------------------------------------------- Troubleshooting: Problems caused by out-dated project information can be addressed by issuing one of the following commands then rebuilding the project: make clean # discard results of previous builds # but keep existing configuration info or make pristine # discard results of previous builds # and restore pre-defined configuration info -------------------------------------------------------------------------------- Sample Output: File System Demo! Creating new file testfile.txt Opened file testfile.txt Data successfully written! Data written:"hello world!" Data successfully read! Data read:"hello world!" Data read matches data written! Truncate tests: Testing shrink to 0 size Testing write after truncating Data successfully written! Data written:"hello world!" Original size of file = 12 File size after shrinking by 5 bytes = 7 Check original contents after shrinking file Data successfully read! Data read:"hello w" File size after expanding by 10 bytes = 17 Check original contents after expanding file Data successfully read! Data read:"hello w" Testing for zeroes in expanded region Closed file testfile.txt File (testfile.txt) deleted successfully! Created dir sub1! Creating new file testfile.txt Opened file testfile.txt Creating new file sub1/testfile.txt Opened file sub1/testfile.txt Data successfully written! Data written:"1" Data successfully written! Data written:"12" Closed file testfile.txt Closed file sub1/testfile.txt Listing dir /: [DIR ] SUB1 [FILE] TESTFILE.TXT (size = 1) Listing dir sub1: [FILE] TESTFILE.TXT (size = 2) Removing files and sub directories in sub1 Removing sub1/TESTFILE.TXT Removed dir sub1! Optimal transfer block size = 512 Allocation unit size = 512 Volume size in f_frsize units = 152 Free space in f_frsize units = 151