orangerpcd
orangerpcd copied to clipboard
mkschreder
Build fails on musl with -Werror=type-limits
orange-rpcd-2.16.08-c4ad159efa5fc40f610fa0cb11e25fda19f131ad referenced by 2.16.09:
OpenWrt-libtool: compile: arm-openwrt-linux-muslgnueabi-gcc -DPACKAGE_NAME=\"orangerpcd\" -DPACKAGE_TARNAME=\"orangerpcd\" -DPACKAGE_VERSION=\"0.1.0\" "-DPACKAGE_STRING=\"orangerpcd 0.1.0\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DPACKAGE=\"orangerpcd\" -DVERSION=\"0.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LUA_H=1 -DHAVE_UCI_H=1 -I. -I/home/bob/openwrt.pac.juci-v2.16.09/staging_dir/target-arm_arm926ej-s_musl-1.1.14_eabi/usr/include -I/home/bob/openwrt.pac.juci-v2.16.09/staging_dir/target-arm_arm926ej-s_musl-1.1.14_eabi/include -I/home/bob/openwrt.pac.juci-v2.16.09/staging_dir/toolchain-arm_arm926ej-s_gcc-5.3.0_musl-1.1.14_eabi/usr/include -I/home/bob/openwrt.pac.juci-v2.16.09/staging_dir/toolchain-arm_arm926ej-s_gcc-5.3.0_musl-1.1.14_eabi/include/fortify -I/home/bob/openwrt.pac.juci-v2.16.09/staging_dir/toolchain-arm_arm926ej-s_gcc-5.3.0_musl-1.1.14_eabi/include -Wall -fPIC -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wwrite-strings -Wswitch -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wmissing-field-initializers -Wextra -Wformat=2 -Wno-format-nonliteral -Wpointer-arith -Wno-missing-braces -Wno-unused-parameter -Wno-unused-variable -Wno-inline -std=gnu99 -fstack-protector-all -Wall -Werror -Os -pipe -march=armv5te -mtune=arm926ej-s -g3 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=soft -iremap /home/bob/openwrt.pac.juci-v2.16.09/build_dir/target-arm_arm926ej-s_musl-1.1.14_eabi/orange-rpcd-2.16.08-c4ad159efa5fc40f610fa0cb11e25fda19f131ad:orange-rpcd-2.16.08-c4ad159efa5fc40f610fa0cb11e25fda19f131ad -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -MT liborange_la-base64.lo -MD -MP -MF .deps/liborange_la-base64.Tpo -c base64.c -fPIC -DPIC -o .libs/liborange_la-base64.o
base64.c: In function 'base64_decode_value':
base64.c:135:15: error: comparison is always false due to limited range of data type [-Werror=type-limits]
if (value_in < 0 || value_in > decoding_size) return -1;
^
base64.c: In function 'base64_decode_block':
base64.c:164:22: error: comparison is always false due to limited range of data type [-Werror=type-limits]
} while (fragment < 0);
^
base64.c:176:22: error: comparison is always false due to limited range of data type [-Werror=type-limits]
} while (fragment < 0);
^
base64.c:189:22: error: comparison is always false due to limited range of data type [-Werror=type-limits]
} while (fragment < 0);
^
base64.c:202:22: error: comparison is always false due to limited range of data type [-Werror=type-limits]
} while (fragment < 0);
^
cc1: all warnings being treated as errors
Makefile:530: recipe for target 'liborange_la-base64.lo' failed
make[5]: *** [liborange_la-base64.lo] Error 1
How can value_in < 0 be always false when value_in is a signed char? Surely it can be negative? Am I missing something? Can you try changing type of value_in and fragment to int and see if that gets rid of the error? Actually it can be slightly more "correct" since if value_in is less than -85 that function will wrap.. so I think using an int there is actually better. Can you see if that fixes it for you?
I have added -Wtype-limits to makefile and changes these to ints for now.
char is not signed char, by c-standard "it's up to the compiler" whether if char denotes an unsigned or signed char. GCC seems to default to unsigned char.
I see. Can we be sure default int is always signed?
On Thu, Sep 8, 2016 at 10:47 AM, Fabian Müller-Knapp < [email protected]> wrote:
char is not signed char, by c-standard "it's up to the compiler" whether if char denotes an unsigned or signed char. GCC seems to default to unsigned char.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mkschreder/orangerpcd/issues/8#issuecomment-245533485, or mute the thread https://github.com/notifications/unsubscribe-auth/AERqiRgYK239dY7OfUxZainAWptdcj0Iks5qn8uzgaJpZM4J12C4 .
I think so. The C89-Draft reads (3.1.2.5):
There are four signed integer types, designated as signed char, short int, int, and long int. (The signed integer and other types may be designated in several additional ways, as described in 3.5.2)
I use c99.
On 8 Sep 2016 11:42, "Fabian Müller-Knapp" [email protected] wrote:
I think so. The C89-Draft reads (3.1.2.5):
There are four signed integer types, designated as signed char, short int, int, and long int. (The signed integer and other types may be designated in several additional ways, as described in 3.5.2)
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/mkschreder/orangerpcd/issues/8#issuecomment-245546829, or mute the thread https://github.com/notifications/unsubscribe-auth/AERqidC7wW-bXZXEbDHUE0349IR39F7Yks5qn9hpgaJpZM4J12C4 .
There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int. (These and other types may be designated in several additional ways, as described in 6.7.2.) There may also be implementation-defined extended signed integer types.25) The standard and extended signed integer types are collectively called signed integer types.26)
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (6.2.5) (this is the C99-final-draft)
Sounds like it answers it. Good.
On 8 Sep 2016 11:51, "Fabian Müller-Knapp" [email protected] wrote:
There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int. (These and other types may be designated in several additional ways, as described in 6.7.2.) There may also be implementation-defined extended signed integer types.25) The standard and extended signed integer types are collectively called signed integer types.26)
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (6.2.5)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mkschreder/orangerpcd/issues/8#issuecomment-245549024, or mute the thread https://github.com/notifications/unsubscribe-auth/AERqiblP6N4KtUR0HvTO5nHOn2yOf0HVks5qn9qXgaJpZM4J12C4 .
Feel free to go over my latest concurrency implementation and see if you notice any issues. I currently run 10 threads that wait on rx queue and as messages arrive they load and run scripts and push back responses to the tx queue in the orange_ws_server which is then handled by the websocket thread (memory caching of scripts will need to go. it is not used anymore). Now you can run long tasks in the lua scripts, like spawning other processes etc and responding when ready without it affecting performance of the rest of the server. I should probably make the number of threads configurable though..
Most important right now is to make sure I have not introduced any concurrency issues in my last few commits. So far both helgrind and drd checks pass on the ws_server unit test. Good idea to add more tests and stress test the server..
On 8 Sep 2016 11:51, "Fabian Müller-Knapp" [email protected] wrote:
There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int. (These and other types may be designated in several additional ways, as described in 6.7.2.) There may also be implementation-defined extended signed integer types.25) The standard and extended signed integer types are collectively called signed integer types.26)
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (6.2.5)
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mkschreder/orangerpcd/issues/8#issuecomment-245549024, or mute the thread https://github.com/notifications/unsubscribe-auth/AERqiblP6N4KtUR0HvTO5nHOn2yOf0HVks5qn9qXgaJpZM4J12C4 .