solve:
almost the Hexadecimal string string->float
such as:
code:float num;
const char *s= "0x123p32lala";
char *p;
num=strtof(s,&p);
printf("num is %f\n",num);
printf("str is %s\n",p);
output:num is 1249835483136.000000
str is lala
but if the input number is much big;
like:
code:const char *s2= "0x999999p100";
num=strtof(s2,&p);
printf("num is %f\n",num);
printf("str is %s\n",p);
corrent : num is 12760587998944832242938906880669384704.000000
real: num is 12760587998944800000000000000000000000.000000
it didn't have enough precision
* libs/libc/stdlib/lib_strtod.c:
(strtod): Add a note about limitations of this implementation
as compared to POSIX in the function's docstring. Also fix a
typo.
* libs/libc/stdlib/lib_strtof.c:
(strtof): Port the changes made to strtod in PR-6952 (commit
c83985c5ce) and add same note as above to docstring.
* libs/libc/stdlib/lib_strtold.c:
(strtold): Same changes as strtof.
For CONFIG_BUILD_KERNEL using the sched/task/task_exithook implementation
will just not work. It calls user code with kernel privileges which is
a bit of a security issue.
follow up the following change:
commit 4262b09cbf
Author: Xiang Xiao <xiaoxiang@xiaomi.com>
Date: Fri Dec 17 02:58:49 2021 +0800
libc: Implement terminal api regardless of CONFIG_SERIAL_TERMIOS setting
since many functions aren't related to termios directly
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
since it's useful to redirect these functions to others
sometime(e.g. validate the memory before write).
Change-Id: I6253a9231af8809e8362f4bc5a1bd67fb094c3b0
since the similar functions(e.g. strdup/strndup) put into libs/libc/string
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ifb2c0c51298b09014748e5ee8275db51213d6911
The previous implementation of strtoul(l) is flawed. The range check
assumed that when overflow happens, the truncated value is smaller than
the original value. As a counter example, passing "10000000000" to
strtol will not trigger ERANGE, but return a truncated value. This patch
adds more accurate range checks.
Change-Id: I239e034e390b4974157ed6efa17110f2e74904cf
Signed-off-by: Peter Bee <bijunda1@xiaomi.com>
and enable on sim as a demo. Here is the paper:
ftp://gcc.gnu.org/pub/gcc/summit/2003/Stackguard.pdf
Signed-off-by: qiaowei <qiaowei@xiaomi.com>
Change-Id: I1926936328dad54eee16b322dcaad0b42f9c4a62
drivers/net/ftmac100.c, libs/libc/stdlib/lib_aligned_alloc.c
A continuation of PRs #1507, #1510, and #1512. See Issue #1481 for additional information.
1.Remove CONFIG_HAVE_INLINE macro
2.Change the ANSI C function to normal function
3.Other simple non ANSI function to macro
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
As it's stated in the standards.
The original code look at the first Xs. It can end up with
an unexpected behavior, if a template contains multiple series of Xs.
E.g. /tmp/XXXXXX/XXXXXX
and update the related stuff in libs/libc/libc.csv
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Id695a7f07bf18a7b4e526297f9131c75ddb79d30
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.
