-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid array-out-of-bounds when building in sourcedir subdir. #624
Conversation
The type of errors avoided looks like this. ../src/common.c:2250:9: bemærk: in expansion of macro »ILOG« ILOG("Ignoring %d bytes of 0x%02x at end of file\n", num_empty, erased_pattern); ^~~~
I'm unable to accept this PR as-is. I'm not sure what problem you are trying to resolve. An out-of-bound should not be possible. Please provide more information about your compiler and path info. |
Hi
I'm using GCC 7.1.1 and cmake 3.8.1 with Ninja as generator
The filesnames from the preprocessor is relative when the output directory is
not outside the source directory. For some reason it does not happen with
"Unix Makefiles" as cmake generator
Like this :
git clone https://github.com/texane/stlink
Cloning into 'stlink'...
remote: Counting objects: 6184, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6184 (delta 0), reused 1 (delta 0), pack-reused 6181
Receiving objects: 100% (6184/6184), 14.72 MiB | 732.00 KiB/s, done.
Resolving deltas: 100% (3818/3818), done.
$ cd stlink
$ mkdir build
$ cd build
$ cmake -G "Ninja" ..
-- The C compiler identification is GNU 7.1.1
-- Check for working C compiler: /lib/ccache/bin/cc
-- Check for working C compiler: /lib/ccache/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- stlink version: 1.4.0-4-g47ce70d
-- Major 1 Minor 4 Patch 0
-- Performing Test C_SUPPORTS_STD_GNU99
-- Performing Test C_SUPPORTS_STD_GNU99 - Success
-- Performing Test C_SUPPORTS_WALL
-- Performing Test C_SUPPORTS_WALL - Success
-- Performing Test C_SUPPORTS_WEXTRA
-- Performing Test C_SUPPORTS_WEXTRA - Success
-- Performing Test C_SUPPORTS_WSHADOW
-- Performing Test C_SUPPORTS_WSHADOW - Success
-- Performing Test C_SUPPORTS_D_FORTIFY_SOURCE_2
-- Performing Test C_SUPPORTS_D_FORTIFY_SOURCE_2 - Success
-- Performing Test C_SUPPORTS_FSTRICT_ALIASING
-- Performing Test C_SUPPORTS_FSTRICT_ALIASING - Success
-- Performing Test C_SUPPORTS_WUNDEF
-- Performing Test C_SUPPORTS_WUNDEF - Success
-- Performing Test C_SUPPORTS_WFORMAT
-- Performing Test C_SUPPORTS_WFORMAT - Success
-- Performing Test C_SUPPORTS_WFORMAT_SECURITY
-- Performing Test C_SUPPORTS_WFORMAT_SECURITY - Success
-- Performing Test C_SUPPORTS_WMAYBE_UNINITIALIZED
-- Performing Test C_SUPPORTS_WMAYBE_UNINITIALIZED - Success
-- Performing Test C_SUPPORTS_WMISSING_VARIABLE_DECLARATIONS
-- Performing Test C_SUPPORTS_WMISSING_VARIABLE_DECLARATIONS - Failed
-- Performing Test C_SUPPORTS_WSHORTEN_64_TO_32
-- Performing Test C_SUPPORTS_WSHORTEN_64_TO_32 - Failed
-- Performing Test C_SUPPORTS_WIMPLICIT_FUNCTION_DECLARATION
-- Performing Test C_SUPPORTS_WIMPLICIT_FUNCTION_DECLARATION - Success
-- Performing Test C_SUPPORTS_WREDUNDANT_DECLS
-- Performing Test C_SUPPORTS_WREDUNDANT_DECLS - Success
-- Performing Test C_SUPPORTS_FPIC
-- Performing Test C_SUPPORTS_FPIC - Success
-- Performing Test C_SUPPORTS_O2
-- Performing Test C_SUPPORTS_O2 - Success
-- Performing Test C_SUPPORTS_WERROR
-- Performing Test C_SUPPORTS_WERROR - Success
-- Found Libusb: /usr/lib/libusb-1.0.so
-- Found PkgConfig: /usr/sbin/pkg-config (found version "0.29.2")
-- Checking for module 'gtk+-3.0'
-- Found gtk+-3.0, version 3.22.18
-- Looking for sys/mman.h
-- Looking for sys/mman.h - found
-- Looking for unistd.h
-- Looking for unistd.h - found
-- Manpage generation disabled
-- Configuring done
-- Generating done
-- Build files have been written to: /home/sgh/tmp/stlink/build
$ ninja
[5/35] Building C object CMakeFiles/stlink-static.dir/src/usb.c.o
FAILED: CMakeFiles/stlink-static.dir/src/usb.c.o
/lib/ccache/bin/cc -DCMAKE_SOURCE_DIR_LENGTH=21 -DSTLINK_HAVE_SYS_MMAN_H -
DSTLINK_HAVE_UNISTD_H -I/usr/include/libusb-1.0 -I../include -Iinclude -I../
src/mingw -std=gnu99 -Wall -Wextra -Wshadow -D_FORTIFY_SOURCE=2 -fstrict-
aliasing -Wundef -Wformat -Wformat-security -Wmaybe-uninitialized -Wimplicit-
function-declaration -Wredundant-decls -fPIC -O2 -Werror -g -MD -MT
CMakeFiles/stlink-static.dir/src/usb.c.o -MF CMakeFiles/stlink-static.dir/src/
usb.c.o.d -o CMakeFiles/stlink-static.dir/src/usb.c.o -c ../src/usb.c
In file included from ../include/stlink/usb.h:15:0,
from ../include/stlink.h:230,
from ../src/usb.c:21:
../src/usb.c: In function ‘_stlink_usb_read_unsupported_reg’:
../include/stlink/logging.h:30:36: error: array subscript is above array
bounds [-Werror=array-bounds]
#define DLOG_HELPER(format, ...) ugly_log(UDEBUG, UGLY_LOG_FILE, format,
__VA_ARGS__)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
…--
Søren Holm
onsdag den 9. august 2017 19.52.59 CEST skrev Jerry Jacobs:
I'm unable to accept this PR as-is. I'm not sure what problem you are trying
to resolve. An out-of-bound should not be possible. Please provide more
information about your compiler and path info.
--
Søren Holm
|
I have not tested with ninja.
Something seems to be really broken with ninja. We need to investigate this more :_( |
Probably because |
Well, technically a string is a "const char*" and adding nume number is ok.
onsdag den 9. august 2017 20.28.40 CEST skrev Jerry Jacobs:
… Probably because `__FILE__` is a string and the length is an number. Clang
has a much more clear error: `error: adding 'int' to a string does not
append to the string [-Werror,-Wstring-plus-int]`
--
Søren Holm
|
Yeah but both GCC and Clang treat it different when building with Ninja. We need to investigate more why this happens. |
Agree
Anyway, now you have the patch to allowig source dir relative __FILE__ paths.
fredag den 11. august 2017 10.43.31 CEST skrev Jerry Jacobs:
… Yeah but both GCC and Clang treat it different when building with Ninja. We
need to investigate more why this happens.
--
Søren Holm
|
Thank you for the PR, but we need to consider a different solution. Further discussion will be proceeded in #628. |
The type of errors avoided looks like this.
../src/common.c:2250:9: bemærk: in expansion of macro »ILOG«
ILOG("Ignoring %d bytes of 0x%02x at end of file\n", num_empty, erased_pattern);
^~~~