such as code: double value = +0x1.000000000000080000000000p-600;
printf("Hello, World!! %.7g:f64\n", value);
expected output : Hello, World!! 2.40992e-181:f64
but real output : Hello, World!! 2.40992e-B1:f64
the reason: we want printf "18", but the flag of character is 'B'
and 'B' is '0'+18,so printf 'B';
but just format the low 32bits if CONFIG_LIBC_LONG_LONG isn't enabled to
avoid to expand the code space to much.
Note: the size will increase 192 bytes on stm32_tiny:nsh.
Before the change:
text data bss dec hex filename
41444 184 1656 43284 a914 nuttx
After the change:
text data bss dec hex filename
41636 184 1656 43476 a9d4 nuttx
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
and remove CONFIG_LIBC_LONG_LONG option to simplify the usage.
note: the size will increase 668
before change:
text data bss dec hex filename
168440 348 4480 173268 2a4d4 nuttx
after change:
text data bss dec hex filename
169108 348 4480 173936 2a770 nuttx
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Show a '%p' thing. A nuttx extension is that the '%p' is followed
by an extra set of alphanumeric characters that are extended format
specifiers.
* - 'S' For symbolic direct pointers (or function descriptors) with offset
* - 's' For symbolic direct pointers (or function descriptors) without offset
printf("%ps %pS\n", ptr, ptr) will print:
module_start module_start+0x0/0x62
Signed-off-by: chao.an <anchao@xiaomi.com>
Modify reason:
When build Nuttx SIM, in x86_64 system:
Compile with gcc option '-m64' (default):
sizeof(double_t) = 8
sizeof(double) = 8
Compile with gcc option '-mx32':
sizeof(double_t) = 8
sizeof(double) = 8
Compile with gcc option '-m32':
sizeof(double_t) = 12 // long double
sizeof(double) = 8
When use '-m32', and print sth. like this:
printf("%f\n", (double)3.0);
SIM will print out: nan
This is because sizeof(double_t) is not equal with double.
Resolve:
replace all double_t to double in libs/libc/stdio.
As a user of '-m32', you should know double_t is one type
long double, and len is 12. And you use use '%lf' to print.
like:
printf("%lf\n", (double_t)3.0);
Currently we don't support '%lf'.
Change-Id: I9b9d11853140d5296dd80416c8ed6a260a9d2d9c
Signed-off-by: ligd <liguiding1@xiaomi.com>
since double_t move from sys/types.h to math.h now and remove
math.h inclusion too because lib_dtoa_engine.h already include
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I3497a73908301d999cf1cfc4a66552a7ca4868c6
* Simplify EINTR/ECANCEL error handling
1. Add semaphore uninterruptible wait function
2 .Replace semaphore wait loop with a single uninterruptible wait
3. Replace all sem_xxx to nxsem_xxx
* Unify the void cast usage
1. Remove void cast for function because many place ignore the returned value witout cast
2. Replace void cast for variable with UNUSED macro
- Numbered arguments now work by using two pass parsing and an argument list.
The maximum number of numbered args is determined by CONFIG_LIBC_NL_ARGMAX
which is then copied into NL_ARGMAX.
- Size of pointer argument ('p') is determined before output.
include/limits.h: Define NL_ARGMAX (as well as some of the other 'invariant
values' per http://pubs.opengroup.org/onlinepubs/7908799/xsh/limits.h.html)
The previous implementation was probably corect. On Cygwin with GCC I see this:
int main(int argc, char **argv)
{
printf("Value 1.2 is: [%f]\n", 1.2);
printf("Value 0.1 is: [%f]\n", 0.1);
printf("Value 0.0: [%f]\n", 0.0);
printf("Value 347.6872: [%f]\n", 347.6872);
}
Generates output
Value 1.2 is: [1.200000]
Value 0.1 is: [0.100000]
Value 0.0: [0.000000]
Value 347.6872: [347.687200]
This reverts commit eb0223bc7f.
libs/libc/stdio/lib_libvsprintf.c: Resolves the integer field width problem if Issue 35 for the cases of long and long long integer types.
libs/libc/stdio/lib_libvsprintf.c: Resolves the integer field width problem if Issue 35 for the case of integer types.
libs/libc/stdio: Remove CONFIG_NOPRINTF_FIELDWIDTH. That option does, indeed, make the printf family of functions much smaller. But it also adds a lot of complexity and makes the functions non-standard. Removing this might break some of the tinier platforms but it is the best thing to do for long term maintanance for for OpenGroup.org compliance.
