jvoisin / fortify-headers Goto Github PK
View Code? Open in Web Editor NEWStandalone portable header-based implementation of FORTIFY_SOURCE=3
License: BSD Zero Clause License
Standalone portable header-based implementation of FORTIFY_SOURCE=3
License: BSD Zero Clause License
They check overlap across the whole range of the given length, but the given length is not what will actually be copied, rather it's the maximum length (if src is shorter, only length of src will be copied). This triggers false positives and traps where it shouldn't (e.g. in ICU tests).
For example when compiling the fgets.c example or any of tests that include stdio.h:
$ "$CC" -Wformat -Wformat-nonliteral -Iinclude -D_FORTIFY_SOURCE=1 -O1 fgets.c
In file included from fgets.c:1:
include/stdio.h: In function 'snprintf':
include/stdio.h:253:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
253 | return __orig_snprintf(__s, __n, __f, __builtin_va_arg_pack());
| ^~~~~~
include/stdio.h: In function 'sprintf':
include/stdio.h:269:17: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
269 | __r = __orig_snprintf(__s, __b, __f, __builtin_va_arg_pack());
| ^~~
include/stdio.h:273:17: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
273 | __r = __orig_sprintf(__s, __f, __builtin_va_arg_pack());
| ^~~
include/stdio.h: In function 'printf':
include/stdio.h:286:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
286 | return __orig_printf(__f, __builtin_va_arg_pack());
| ^~~~~~
include/stdio.h: In function 'fprintf':
include/stdio.h:300:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral]
300 | return __orig_fprintf(__s, __f, __builtin_va_arg_pack());
| ^~~~~~
$ "$CC" --version
mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r20028-43d71ad93e) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is probably a gcc bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110834), however the practical effect of this is that it’s not possible to use FORTIFY and format-nonliteral enforcement in a project at the same time, both of which are very useful from a security perspective.
A concrete example of this is in the context of OpenWrt (openwrt/openwrt#13016), which is currently using the “1.1” version of this project from 2f30.org.
Since, from the point of view of an application, stdio.h is a system header, it’s messy to work around this in an application project directly. Until the gcc bug is fixed (which will probably take a long time), a viable workaround could be to simply suppress this warning within the affected wrapper functions in the fortify-headers stdio.h.
/opt/hostedtoolcache/CodeQL/2.14.1/x64/codeql/codeql database finalize --finalize-dataset --threads=2 --ram=5907 /home/runner/work/_temp/codeql_databases/cpp
CodeQL detected code written in C/C++ but could not process any of it. Review our troubleshooting guide at https://gh.io/troubleshooting-code-scanning/no-source-code-seen-during-build.
Error: Encountered a fatal error while running "/opt/hostedtoolcache/CodeQL/2.14.1/x64/codeql/codeql database finalize --finalize-dataset --threads=2 --ram=5907 /home/runner/work/_temp/codeql_databases/cpp". Exit code was 32 and error was: CodeQL detected code written in C/C++ but could not process any of it. Review our troubleshooting guide at https://gh.io/troubleshooting-code-scanning/no-source-code-seen-during-build.
16:49 <@q66> we'll need to go through all new fortifications you added and check them against libc headers
16:49 <@q66> following musl's headers is a good idea for this because afaik musl already tries to be the strictest in terms of what it makes available and when
16:50 <@q66> so in a "looser" libc you won't get a breakage but rather you'll just lose fortify for that one func
As reported by @q66 on irc:
/usr/include/fortify/poll.h:39:2: error: use of undeclared identifier 'size_t'; did you mean 'sizeof'?
39 | size_t __b = __bos(__f, 0);
| ^
/usr/include/fortify/poll.h:39:13: error: expression is not assignable
39 | size_t __b = __bos(__f, 0);
| ~~~~~~~~~~ ^
/usr/include/fortify/poll.h:39:9: error: use of undeclared identifier '__b'
39 | size_t __b = __bos(__f, 0);
| ^
/usr/include/fortify/poll.h:41:12: error: use of undeclared identifier '__b'
41 | if (__n > __b / sizeof(struct pollfd))
| ^
/usr/include/fortify/poll.h:54:2: error: use of undeclared identifier 'size_t'; did you mean 'sizeof'?
54 | size_t __b = __bos(__f, 0);
| ^
/usr/include/fortify/poll.h:54:13: error: expression is not assignable
54 | size_t __b = __bos(__f, 0);
| ~~~~~~~~~~ ^
/usr/include/fortify/poll.h:54:9: error: use of undeclared identifier '__b'
54 | size_t __b = __bos(__f, 0);
| ^
/usr/include/fortify/poll.h:56:12: error: use of undeclared identifier '__b'; did you mean '__n'?
56 | if (__n > __b / sizeof(struct pollfd))
| ^
/usr/include/fortify/poll.h:51:72: note: '__n' declared here
51 | _FORTIFY_FN(ppoll) int ppoll(struct pollfd * _FORTIFY_POS0 __f, nfds_t __n,
The current implementation is wrong: it's valid to pass a buffer smaller than MB_CUR_MAX
to wctomb
. The only thing we can do is check that the return value of wctomb
is smaller than the size of the buffer.
clang's documentation says:
__has_builtin should not be used to detect support for a builtin macro; use #ifdef instead.
So I guess we'll have to use something like #if defined(foo) || __has_builtin(foo)
, sigh.
Coverage was added in c4247e4 and is available at https://jvoisin.github.io/fortify-headers/include/index.html
For example, in strcpy
(ignoring the UB overlapping check):
fortify-headers/include/string.h
Lines 139 to 150 in 9aa4490
By the time, __orig_strcpy
is called, the length has already been computed and has been established to be in bound. There's no need to pay for the nul-byte search again inside of __orig_strcpy
when the faster memcpy
can be called instead.
Some of the other str*
functions suffer from the same issue.
Wrong parameters passed to open
should be detected.
Until C23, if new_size
is zero, the behavior is implementation defined (null pointer may be returned (in which case the old memory block may or may not be freed), or some non-null pointer may be returned that may not be used to access storage). Such usage is deprecated (via C DR 400).(since C17)
Since C23, if new_size
is zero, the behavior is undefined.
The conservative thing to do is to only catch new_size=0
when compiling with C23, but I'm wondering if we should always return NULL
otherwise.
Make use of diagnose_if
for things like:
memset
called n
set to 0
, likely indicating that arguments got inverted.realpath
with path
set to NULL
, likely indicating that arguments got inverted.umask
with mode & ~0777
.And add tests for it.
16:47 <@q66> e.g. fdopen needs to be behind
16:47 <@q66> #if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \
16:47 <@q66> || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) \
16:47 <@q66> || defined(_BSD_SOURCE)
16:47 <@q66> but that's for a separate PR
16:48 <@q66> same with fmemopen etc
I just noticed that the test runner does not actually fail on any failures.
Documentation:
Implementations:
User-facing documentation
Tests:
If only to check that fortify-header gracefully handle hobby-scale compilers.
Something like:
void *memcpy(void *d, const void *s, size_t __n) {
if (__builtin_constant_p(__n) && __n > __bos(od)) {
compile-time-error!
}
}
Apparently, the trick everyone is using to make the compiler choke is this one:
#define __errordecl(name, msg) extern void name(void) __attribute__((__error__(msg)))
#define __warnattr(msg) __attribute__((__warning__(msg)))
This should be used only when warning_if
isn't supported.
To prevent things like 95441d2 from happening.
Inspiration can be taken from chimera-linux/fortify-headers@1d39f55 and chimera-linux/fortify-headers@55ae398
eg.
#define snprintf(str, len, ...) \
__builtin___snprintf_chk(str, len, 0, builtin_object_size(str), __VA_ARGS__)
GCC 12 has those for memcpy, mempcpy, memmove, memset, strcpy, stpcpy, strncpy, strcat and strncat.
I disabled it for now, but the str(r)chr hardening is currently UB and it crashes several parts of the Python test suite. I don't know if the NULL subtraction is the sole part, but it's the only I can think of right now.
As said by Dmytro Hrybenko:
consider adding a hyrum's law buster until you are ready to support c++
#ifdef __cplusplus
#error this library only supports C
#endif
memrchr
: glibc trash.memchr
rawmemchr
: deprecated glibc trash.strchr
strrchr
FAILED: lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/eprintf.c.o
/builddir/llvm-bootstrap-17.0.6/build/./bin/clang --target=x86_64-chimera-linux-musl -DVISIBILITY_HIDDEN -Wformat -Werror=format-security -ftrivial-auto-var-init=zero -fstack-clash-protection -O2 -pipe -ffile-prefix-map=/builddir/llvm-bootstrap-17.0.6=. -fPIC -O3 -DNDEBUG -m32 -fno-lto -std=c11 -fno-builtin -fvisibility=hidden -fomit-frame-pointer -DCOMPILER_RT_HAS_FLOAT16 -MD -MT lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/eprintf.c.o -MF lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/eprintf.c.o.d -o lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/eprintf.c.o -c /builddir/llvm-bootstrap-17.0.6/compiler-rt/lib/builtins/eprintf.c
In file included from /builddir/llvm-bootstrap-17.0.6/compiler-rt/lib/builtins/eprintf.c:10:
/usr/include/fortify/stdio.h:150:47: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 2 of function '__orig_vsnprintf' has type 'size_t' (aka 'unsigned long'), but parameter 2 of function '__builtin_vsnprintf' has type 'unsigned int'
150 | __diagnose_as_builtin(__builtin_vsnprintf, 1, 2, 3, 4)
| ^
1 error generated.
[105/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/udivsi3.c.o
[106/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/udivti3.c.o
[107/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/clear_cache.c.o
[108/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/i386/fp_mode.c.o
[109/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/umodsi3.c.o
[110/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/enable_execute_stack.c.o
[111/310] Building C object lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/emutls.c.o
FAILED: lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/emutls.c.o
/builddir/llvm-bootstrap-17.0.6/build/./bin/clang --target=x86_64-chimera-linux-musl -DVISIBILITY_HIDDEN -Wformat -Werror=format-security -ftrivial-auto-var-init=zero -fstack-clash-protection -O2 -pipe -ffile-prefix-map=/builddir/llvm-bootstrap-17.0.6=. -fPIC -O3 -DNDEBUG -m32 -fno-lto -std=c11 -fno-builtin -fvisibility=hidden -fomit-frame-pointer -DCOMPILER_RT_HAS_FLOAT16 -MD -MT lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/emutls.c.o -MF lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/emutls.c.o.d -o lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/emutls.c.o -c /builddir/llvm-bootstrap-17.0.6/compiler-rt/lib/builtins/emutls.c
In file included from /builddir/llvm-bootstrap-17.0.6/compiler-rt/lib/builtins/emutls.c:11:
/usr/include/fortify/string.h:45:47: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_memcpy' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_memcpy' has type 'unsigned int'
45 | __diagnose_as_builtin(__builtin_memcpy, 1, 2, 3)
| ^
/usr/include/fortify/string.h:70:48: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_memmove' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_memmove' has type 'unsigned int'
70 | __diagnose_as_builtin(__builtin_memmove, 1, 2, 3)
| ^
/usr/include/fortify/string.h:89:47: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_memset' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_memset' has type 'unsigned int'
89 | __diagnose_as_builtin(__builtin_memset, 1, 2, 3)
| ^
/usr/include/fortify/string.h:107:47: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_memchr' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_memchr' has type 'unsigned int'
107 | __diagnose_as_builtin(__builtin_memchr, 1, 2, 3)
| ^
/usr/include/fortify/string.h:262:48: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_strncat' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_strncat' has type 'unsigned int'
262 | __diagnose_as_builtin(__builtin_strncat, 1, 2, 3)
| ^
/usr/include/fortify/string.h:285:48: error: 'diagnose_as_builtin' attribute parameter types do not match: parameter 3 of function '__orig_strncpy' has type 'size_t' (aka 'unsigned long'), but parameter 3 of function '__builtin_strncpy' has type 'unsigned int'
285 | __diagnose_as_builtin(__builtin_strncpy, 1, 2, 3)
| ^
6 errors generated.
trying to reproduce normally with -fno-builtin
or similar doesn't repro, so there is probably something funny in the compiler-rt build
I've been testing using these headers on one of Gentoo build servers and found an issue where crossdev (Gentoo's cross compile toolchain tool) can no longer build musl toolchains.
This was an old bug in Gentoo which was solved a long time ago ( https://bugs.gentoo.org/498114 ) but for some reason when fortify headers is enabled it fails but disabling it makes it work again. I'm stumped as to what could be the cause but more than happy to test any suggestions while I keep looking into possible causes as I really don't know why these headers are causing the issue.
Error:
checking whether compiler's long double definition matches float.h... no
./configure: error: unsupported long double type
ERROR: cross-mipsel-unknown-linux-musl/musl-1.2.4::local failed (configure phase):
Steps to reproduce:
/etc/portage/patches/sys-devel/gcc
emerge -va sys-devel/gcc
emerge -va sys-devel/crossdev
crossdev -s4 mipsel-unknown-linux-musl
Full build log:
Calculating dependencies
* IMPORTANT: 16 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
... done!
Dependency resolution took 1.36 s.
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) cross-mipsel-unknown-linux-musl/musl-1.2.4::local
* musl-1.2.4.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ]
* getconf.c BLAKE2B SHA512 size ;-) ... [ ok ]
* musl-getent-93a08815f8598db442d8b766b463d0150ed8e2ab.c BLAKE2B SHA512 size ;-) ... [ ok ]
* iconv.c BLAKE2B SHA512 size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking musl-1.2.4.tar.gz to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
>>> Unpacking getconf.c to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
unpack getconf.c: file format not recognized. Ignoring.
>>> Unpacking musl-getent-93a08815f8598db442d8b766b463d0150ed8e2ab.c to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
unpack musl-getent-93a08815f8598db442d8b766b463d0150ed8e2ab.c: file format not recognized. Ignoring.
>>> Unpacking iconv.c to /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
unpack iconv.c: file format not recognized. Ignoring.
>>> Source unpacked in /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work
>>> Preparing source in /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4 ...
gcc
checking for C compiler... gcc
checking whether C compiler works... yes
checking whether compiler accepts -Werror=unknown-warning-option... no
checking whether compiler accepts -Werror=unused-command-line-argument... no
checking whether compiler accepts -Werror=ignored-optimization-argument... no
checking whether linker accepts -Werror=unknown-warning-option... no
checking whether linker accepts -Werror=unused-command-line-argument... no
checking for C compiler family... gcc
checking target system type... mipsel-unknown-linux-musl
checking whether compiler accepts -std=c99... yes
checking whether compiler accepts -nostdinc... yes
checking whether compiler accepts -ffreestanding... yes
checking whether compiler accepts -fexcess-precision=standard... yes
checking whether compiler accepts -frounding-math... yes
checking whether compiler accepts -fno-strict-aliasing... yes
checking whether compiler needs attribute((may_alias)) suppression... no
checking whether compiler accepts -Wa,--noexecstack... yes
checking whether compiler accepts -fno-stack-protector... yes
checking whether compiler accepts -fno-tree-loop-distribute-patterns... yes
checking whether we should preprocess assembly to add debugging information... no
checking for optimization settings... using provided CFLAGS
checking whether compiler accepts -pipe... yes
checking whether compiler accepts -fomit-frame-pointer... yes
checking whether compiler accepts -fno-unwind-tables... yes
checking whether compiler accepts -fno-asynchronous-unwind-tables... yes
checking whether compiler accepts -ffunction-sections... yes
checking whether compiler accepts -fdata-sections... yes
checking whether compiler accepts -Wno-pointer-to-int-cast... yes
checking whether compiler accepts -Werror=implicit-function-declaration... yes
checking whether compiler accepts -Werror=implicit-int... yes
checking whether compiler accepts -Werror=pointer-sign... yes
checking whether compiler accepts -Werror=pointer-arith... yes
checking whether compiler accepts -Werror=int-conversion... yes
checking whether compiler accepts -Werror=incompatible-pointer-types... yes
checking whether compiler accepts -Werror=discarded-qualifiers... yes
checking whether compiler accepts -Werror=discarded-array-qualifiers... yes
checking whether compiler accepts -Waddress... yes
checking whether compiler accepts -Warray-bounds... yes
checking whether compiler accepts -Wchar-subscripts... yes
checking whether compiler accepts -Wduplicate-decl-specifier... yes
checking whether compiler accepts -Winit-self... yes
checking whether compiler accepts -Wreturn-type... yes
checking whether compiler accepts -Wsequence-point... yes
checking whether compiler accepts -Wstrict-aliasing... yes
checking whether compiler accepts -Wunused-function... yes
checking whether compiler accepts -Wunused-label... yes
checking whether compiler accepts -Wunused-variable... yes
checking preprocessor condition __PIC__... true
checking whether linker accepts -Wl,--sort-section,alignment... yes
checking whether linker accepts -Wl,--sort-common... yes
checking whether linker accepts -Wl,--gc-sections... yes
checking whether linker accepts -Wl,--hash-style=both... yes
checking whether linker accepts -Wl,--no-undefined... yes
checking whether linker accepts -Wl,--exclude-libs=ALL... yes
checking whether linker accepts -Wl,--dynamic-list=./dynamic.list... yes
checking whether linker accepts -lgcc... yes
checking whether linker accepts -lgcc_eh... yes
using compiler runtime libraries: -lgcc -lgcc_eh
checking preprocessor condition __mips_isa_rev >= 6... false
checking preprocessor condition _MIPSEL || __MIPSEL || __MIPSEL__... false
checking preprocessor condition __mips_soft_float... false
checking whether compiler's long double definition matches float.h... no
./configure: error: unsupported long double type
* ERROR: cross-mipsel-unknown-linux-musl/musl-1.2.4::local failed (configure phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 136: Called src_configure
* environment, line 1735: Called die
* The specific snippet of code:
* ./configure --target=${CTARGET} --prefix="${EPREFIX}${sysroot}/usr" --syslibdir="${EPREFIX}${sysroot}/lib" --disable-gcc-wrapper || die
*
* If you need support, post the output of `emerge --info '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`,
* the complete build log and the output of `emerge -pqv '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`.
* The complete build log is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/environment'.
* Working directory: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'
* S: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'
>>> Failed to emerge cross-mipsel-unknown-linux-musl/musl-1.2.4, Log file:
>>> '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/build.log'
* Messages for package cross-mipsel-unknown-linux-musl/musl-1.2.4:
* ERROR: cross-mipsel-unknown-linux-musl/musl-1.2.4::local failed (configure phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 136: Called src_configure
* environment, line 1735: Called die
* The specific snippet of code:
* ./configure --target=${CTARGET} --prefix="${EPREFIX}${sysroot}/usr" --syslibdir="${EPREFIX}${sysroot}/lib" --disable-gcc-wrapper || die
*
* If you need support, post the output of `emerge --info '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`,
* the complete build log and the output of `emerge -pqv '=cross-mipsel-unknown-linux-musl/musl-1.2.4::local'`.
* The complete build log is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/temp/environment'.
* Working directory: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'
* S: '/var/tmp/portage/cross-mipsel-unknown-linux-musl/musl-1.2.4/work/musl-1.2.4'
In /usr/include/x86_64-linux-gnu/sys/cdefs.h
, there is the following:
/* Fortify support. */
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1)
#define __bos0(ptr) __builtin_object_size (ptr, 0)
and for some reasons, clang thinks it's a great idea to go look there, colliding with our own __bos
macro:
$ ~/dev/fortify-headers make -C tests/ clean clang
make: Entering directory '/home/jvoisin/dev/fortify-headers/tests'
In file included from test_FD_CLR_SETSIZE.c:1:
In file included from ./common.h:19:
In file included from ../include/unistd.h:26:
../include/fortify-headers.h:63:9: warning: '__bos' macro redefined [-Wmacro-redefined]
#define __bos(ptr, type) __builtin_dynamic_object_size (ptr, type)
^
/usr/include/x86_64-linux-gnu/sys/cdefs.h:123:9: note: previous definition is here
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1)
$
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.