I am new to Frama-C and I am trying to formally verify a code base that contains a significant number of multiline macro definitions which look like this:
#define vector_setElement(w,x,i) \
_Generic \
( \
(x), \
const int8_t : vector_setElement_INT8 , \
int8_t : vector_setElement_INT8 , \
const uint8_t : vector_setElement_UINT8 , \
uint8_t : vector_setElement_UINT8 , \
const int16_t : vector_setElement_INT16 , \
int16_t : vector_setElement_INT16 , \
const uint16_t : vector_setElement_UINT16 , \
uint16_t : vector_setElement_UINT16 , \
const int32_t : vector_setElement_INT32 , \
int32_t : vector_setElement_INT32 , \
const uint32_t : vector_setElement_UINT32 , \
uint32_t : vector_setElement_UINT32 , \
const int64_t : vector_setElement_INT64 , \
int64_t : vector_setElement_INT64 , \
const uint64_t : vector_setElement_UINT64 , \
uint64_t : vector_setElement_UINT64 , \
) \
(w, x, i)
However when I run Frama-C on the use of this macro definition, I get a parser syntax error at the location of the use of the macro definition. I tried this with many different multiline macro definitions and a parser syntax error always occurs at the location of the use of the macro definition.
So, my questions are:
Does Frama-C support multiline macro definitions? If so, what do I need to do to fix the parser errors?
Also, I know Frama-C supports some C11 constructs, does that include _Generic?
*** Update - Solution ***
It turns out _Generic is the reason for the syntax errors with multiline macro definitions. Multiline macro definitions that I thought do not use _Generic, in fact do use it beneath a few other function and macro calls. Multiline macro definitions without _Generic parse completely fine.
Frama-C relies on an external pre-processor (default is given by the corresponding autoconf macro at compile time) to perform macro expansions, thus multi-line macros should not be a problem (and if it were, this would be an issue with your pre-processor, not with Frama-C). On the other hand, _Generic is indeed not among C11 features that Frama-C does support at this time.
Frama-C is C so it does support it, not sure about _Generics though, which is possibly why the escape is not working in this case.
Related
I am new to Frama-C framework and I am trying to do some contract testing with C programs. I intend to use E-ACSL plugin for this, and I tried a test program to see how it works, but I get some compilation errors. Here is my code:
#include <stdio.h>
#include <stdlib.h>
int main(void) {
int x = 0;
/*# assert x == 1;*/
/*# assert x == 0;*/
return 0;
}
Then, here is the Frama-C annotated code:
/* Generated by Frama-C */
#include "stdio.h"
#include "stdlib.h"
struct __e_acsl_mpz_struct {
int _mp_alloc ;
int _mp_size ;
unsigned long *_mp_d ;
};
typedef struct __e_acsl_mpz_struct __e_acsl_mpz_struct;
typedef __e_acsl_mpz_struct ( __attribute__((__FC_BUILTIN__)) __e_acsl_mpz_t)[1];
/*# ghost extern int __e_acsl_init; */
/*# ghost extern int __e_acsl_internal_heap; */
extern size_t __e_acsl_heap_allocation_size;
/*#
predicate diffSize{L1, L2}(ℤ i) =
\at(__e_acsl_heap_allocation_size,L1) -
\at(__e_acsl_heap_allocation_size,L2) ≡ i;
*/
int main(void)
{
int __retres;
int x = 0;
/*# assert x ≡ 1; */ ;
/*# assert x ≡ 0; */ ;
__retres = 0;
return __retres;
}
Finally, I try to compile it with gcc and the flags the manual indicates (page 13) but I get the following errors (and warnings):
$ gcc monitored_second.c -o monitored_second -leacsl -leacsl-gmp -leacsl -jemalloc -lpthread -lm
monitored_second.c:10:1: warning: ‘__FC_BUILTIN__’ attribute directive ignored [-Wattributes]
typedef __e_acsl_mpz_struct ( __attribute__((__FC_BUILTIN__)) __e_acsl_mpz_t)[1];
monitored_second.c:18:55: warning: ‘__FC_BUILTIN__’ attribute directive ignored [-Wattributes]
int line);
^
monitored_second.c:25:60: warning: ‘__FC_BUILTIN__’ attribute directive ignored [-Wattributes]
size_t ptr_size);
^
/usr/bin/ld: cannot find -leacsl
/usr/bin/ld: cannot find -leacsl-jemalloc
collect2: error: ld returned 1 exit status
I've also removed the "-rtl-bittree" label because it returns another error.
Frama-C version is the latest: Sulfur-20171101
Got any idea of what is happening?
Thanks!
Normally, you should have a script called e-acsl-gcc.sh installed in the same directory as frama-c binary, that can take care of calling gcc with appropriate options. Its basic usage is documented in section 2.2 of the manual, and man e-acsl-gcc.sh gives more details on the options that can be used. In short, you should be able to type
e-acsl-gcc.sh -c \
--oexec-eacsl=first_monitored \
--oexec=first \
--ocode=first_monitored.i \
first.i
to obtain
an executable first_monitored with the e-acsl instrumentation
an executable first with the original program
a source file first_monitored.i with the e-acsl generated C code
Edit Looking at the linking command used by the script, I'd say that the command line proposed earlier in the manual is out of date (in particular, it refers to eacsl-jemalloc whereas e-acsl-gcc.sh seems to prefer eacsl-dlmalloc), which could probably be reported as a bug at https://bts.frama-c.com
I have created an extern in a javascript file and specified it as part of the Google Closure Compiler (GCC) command line option. I am compiling with advanced mode. GCC is taking the function in my extern and placing it in the compiled code. I have no idea why it would do this. GCC is suppose to recognize that the extern function is in a separate file. When I export the object, it will rename the object and leave the object's function names alone BUT it will create a copy of the entire extern function in the compiled code.
I have tried many variations (too numerous here to list) to see how to prevent GCC from doing this but nothing has worked.
My extern:
var MyCustomResizer = {
"onResize": function (a, b) {
},
"detach": function () {
}
}
I exported the object as follows:
window["MyCustomResizer"] = MyCustomResizer;
My app using the "detach" function:
MyCustomResizer.detach();
My compiler settings:
java -jar closure-compiler/compiler.jar \
--compilation_level ADVANCED_OPTIMIZATIONS \
--externs scripts/externs/resizer-extern.js \
--js_output_file scripts/release/myapp.js \
--warning_level VERBOSE \
--language_out ECMASCRIPT5 \
--language_in=ECMASCRIPT_2017 \
--js scripts/base.js
And the generated compiled output contains this:
ha.detach();
...
var ha = {
onResize: function () {
}, detach: function () {
}
};
It turns out that when you specify extern files, you MUST use the --extern option in front of every extern file. I only had it on the first one:
Incorrect:
java -jar closure-compiler/compiler.jar \
--compilation_level ADVANCED_OPTIMIZATIONS \
--externs scripts/externs/jQuery/jquery-1.9-externs.js \
scripts/externs/third-party.js \
--js_output_file scripts/release/servetus-min.js \
Correct:
java -jar closure-compiler/compiler.jar \
--compilation_level ADVANCED_OPTIMIZATIONS \
--externs scripts/externs/jQuery/jquery-1.9-externs.js \
--externs scripts/externs/third-party.js \
--js_output_file scripts/release/servetus-min.js \
I find it very strange that the compiler just ignores the one without the --externs but just goes ahead anyway and copies its functions into the compiled code. This should not be allowed and a warning should be issued. This took an entire day to track down.
I have installed the ESP8266 SDK and toolchain and try to build the project CDataCollectionDemo which is generated from kaa sandbox. And I get the error like this
/opt/Espressif/esp-rtos-sdk/include/espressif/c_types.h:47:29: error: conflicting types for ‘size_t’
typedef unsigned int size_t;
^
In file included from /opt/Espressif/esp-rtos-sdk/extra_include/string.h:14:0,
from /home/tung/kaa/project/CDataCollectionDemo/targets/esp8266/target.
here is the full output
tung#ubuntu:~/kaa/project/CDataCollectionDemo$ sudo ./build.sh deploy
-- The C compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
==================================
BUILD_TYPE = (Default)
KAA_PLATFORM = posix
KAA_MAX_LOG_LEVEL = 3
==================================
BOOTSTRAP ENABLED
PROFILE ENABLED
USER EXTENSION ENABLED
CONFIGURATION ENABLED
EVENTS ENABLED
LOGGING ENABLED
NOTIFICATION ENABLED
ENCRYPTION ENABLED
KAA WILL BE INSTALLED TO /usr/local
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Could NOT find cppcheck
-- WiFi AP: WiFi SSID
-- WiFi Pass:
-- Configuring done
-- Generating done
-- Build files have been written to: /home/tung/kaa/project/CDataCollectionDemo/build
Scanning dependencies of target target_support
[ 1%] Building C object targets/esp8266/CMakeFiles/target_support.dir/target.c.o
In file included from /opt/Espressif/esp-rtos-sdk/extra_include/sys/config.h:4:0,
from /opt/Espressif/esp-rtos-sdk/extra_include/_ansi.h:16,
from /opt/Espressif/esp-rtos-sdk/extra_include/string.h:10,
from /home/tung/kaa/project/CDataCollectionDemo/targets/esp8266/target.c:17:
/opt/Espressif/esp-rtos-sdk/extra_include/machine/ieeefp.h:277:2: error: #error Endianess not declared!!
#error Endianess not declared!!
^
In file included from /opt/Espressif/esp-rtos-sdk/include/espressif/esp_common.h:9:0,
from /opt/Espressif/esp-rtos-sdk/include/freertos/portmacro.h:73,
from /opt/Espressif/esp-rtos-sdk/include/freertos/portable.h:318,
from /opt/Espressif/esp-rtos-sdk/include/freertos/FreeRTOS.h:87,
from /home/tung/kaa/project/CDataCollectionDemo/targets/esp8266/target.c:19:
/opt/Espressif/esp-rtos-sdk/include/espressif/c_types.h:47:29: error: conflicting types for ‘size_t’
typedef unsigned int size_t;
^
In file included from /opt/Espressif/esp-rtos-sdk/extra_include/string.h:14:0,
from /home/tung/kaa/project/CDataCollectionDemo/targets/esp8266/target.c:17:
/usr/lib/gcc/x86_64-linux-gnu/4.8/include/stddef.h:212:23: note: previous declaration of ‘size_t’ was here
typedef __SIZE_TYPE__ size_t;
^
In file included from /opt/Espressif/esp-rtos-sdk/include/espressif/esp_common.h:10:0,
from /opt/Espressif/esp-rtos-sdk/include/freertos/portmacro.h:73,
from /opt/Espressif/esp-rtos-sdk/include/freertos/portable.h:318,
from /opt/Espressif/esp-rtos-sdk/include/freertos/FreeRTOS.h:87,
from /home/tung/kaa/project/CDataCollectionDemo/targets/esp8266/target.c:19:
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:10:7: error: conflicting types for ‘strncpy’
char *strncpy(char *dst, const char *src, size_t n);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:12:5: error: conflicting types for ‘strncmp’
int strncmp(const char *s1, const char *s2, size_t n);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:13:8: error: conflicting types for ‘strlen’
size_t strlen(const char *s);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:16:7: error: conflicting types for ‘strncat’
char *strncat(char *dst, const char *src, size_t count);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:17:8: error: conflicting types for ‘strspn’
size_t strspn(const char *s, const char *accept);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:18:8: error: conflicting types for ‘strcspn’
size_t strcspn(const char *s, const char *reject);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:26:6: error: conflicting types for ‘bzero’
void bzero(void *s, size_t n);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:28:7: error: conflicting types for ‘memcpy’
void *memcpy(void *dst, const void *src, size_t n);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:29:7: error: conflicting types for ‘memset’
void *memset(void *dst, int c, size_t n);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:30:5: error: conflicting types for ‘memcmp’
int memcmp(const void *m1, const void *m2, size_t n);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:31:7: error: conflicting types for ‘memmove’
void *memmove(void *dst, const void *src, size_t n);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:37:5: warning: conflicting types for built-in function ‘snprintf’ [enabled by default]
int snprintf(char *buf, unsigned int count, const char *format, ...);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:41:7: warning: conflicting types for built-in function ‘malloc’ [enabled by default]
void *malloc(size_t n);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:43:7: warning: conflicting types for built-in function ‘calloc’ [enabled by default]
void *calloc(size_t c, size_t n);
^
/opt/Espressif/esp-rtos-sdk/include/espressif/esp_libc.h:45:7: warning: conflicting types for built-in function ‘realloc’ [enabled by default]
void *realloc(void *p, size_t n);
^
make[2]: *** [targets/esp8266/CMakeFiles/target_support.dir/target.c.o] Error 1
make[1]: *** [targets/esp8266/CMakeFiles/target_support.dir/all] Error 2
make: *** [all] Error 2
./build.sh: 52: ./build.sh: ./demo_client: not found
Everything I did follow the kaa documentation, except adding the -DKAA_PLATFORM=esp8266 argument to cmake command in build.sh file. Can you tell me what's problem here and how to fix it. Thank you!
Update
I have added some arguments to cmake command as #MrKoin suggested but still get an error
Cmake arguments
cmake .. \
-DCMAKE_TOOLCHAIN_FILE=../libs/kaa/toolchains/esp8266.cmake \
-DKAA_PLATFORM=esp8266 \
-DCMAKE_BUILD_TYPE=MinSizeRel \
Output
In file included from /home/tung/kaa/project/CDataCollectionDemo/libs/kaa/thirdparty/mbedtls/aes.c:27:0:
/opt/Espressif/crosstool-NG/builds/xtensa-lx106-elf/lib/gcc/xtensa-lx106-elf/4.8.2/include/stdint.h:9:26: fatal error: stdint.h: No such file or directory
# include_next <stdint.h>
^
compilation terminated.
make[2]: *** [libs/kaa/tools/kaa_encryption/rsa_key_gen/mbedtls/CMakeFiles/mbedtls.dir/aes.c.obj] Error 1
make[1]: *** [libs/kaa/tools/kaa_encryption/rsa_key_gen/mbedtls/CMakeFiles/mbedtls.dir/all] Error 2
make: *** [all] Error 2
It seems like some libraries missing. What should I do now? Thanks!
Looks like you need to specify cmake toolchain file in cmake arguments:
cmake -DCMAKE_TOOLCHAIN_FILE=../libs/kaa/toolchains/esp8266.cmake \
-DKAA_PLATFORM=esp8266 ..
Please, refer documentation for details.
It might be related to step 5 Install ESP8266 RTOS SDK in the tutorial you referenced from the Kaa website.
Did you run the command sed -i 's:#include "c_types.h"://#include "c_types.h":' $ESP_SDK_HOME/include/lwip/arch/cc.h?
I remember I had a similar (or the same) problem and forgot to execute this command. It comments out an #include which conflicts with the declaration of types elsewhere.
You need to edit the build.sh file,
find build() and change the code:
build() {
mkdir -p "$PROJECT_HOME/build"
cd "$PROJECT_HOME/build"
cmake ..\
-DKAA_TARGET=esp8266\
-DCMAKE_TOOLCHAIN_FILE=../libs/kaa/toolchains/esp8266.cmake \
-DBUILD_TESTING=OFF \
-DKAA_PLATFORM=esp8266 \
-DBUILD_TESTING=OFF \
-DCMAKE_BUILD_TYPE=MinSizeRel
make
}
I know that g++ support constexpr math function. I want to do that on clang++. So I write a simple code.
#include<iostream>
#include<cmath>
int main()
{
constexpr auto a(std::floor(4.3));
std::cout<<a<<std::endl;
}
and then use clang++-libc++ -std=c++1y to compile it and the get the following error:
error: constexpr variable 'a' must be initialized by a constant expression
constexpr auto a(std::floor(4.3));
^ ~~~~~~~~~~~~~~~
note: non-constexpr function 'floor' cannot be used in a constant expression
constexpr auto a(std::floor(4.3));
^
/usr/include/x86_64-linux-gnu/bits/mathcalls.h:184:14: note: declared here
__MATHCALLX (floor,, (_Mdouble_ __x), (__const__));
^
/usr/include/math.h:58:26: note: expanded from macro '__MATHCALLX'
__MATHDECLX (_Mdouble_,function,suffix, args, attrib)
^
/usr/include/math.h:60:22: note: expanded from macro '__MATHDECLX'
__MATHDECL_1(type, function,suffix, args) __attribute__ (attrib); \
^
/usr/include/math.h:63:31: note: expanded from macro '__MATHDECL_1'
extern type __MATH_PRECNAME(function,suffix) args __THROW
^
/usr/include/math.h:66:42: note: expanded from macro '__MATH_PRECNAME'
#define __MATH_PRECNAME(name,r) __CONCAT(name,r)
^
/usr/include/x86_64-linux-gnu/sys/cdefs.h:88:23: note: expanded from macro '__CONCAT'
#define __CONCAT(x,y) x ## y
I use clang-3.5. So I want to ask whether clang++ support constexpr math function. If so, what compiler flag I need to pass to clang?
cppreference doesn't declare std::floor as constexpr. Not sure whether any standard does. I guess compilers might want to avoid implementing this unless it's in some standard, to avoid incompatible behavior. According to the manual, clang aims for support of C++11 and C++1y (likely C++14), with no extensions of C++ features mentioned.
I would like to change a program to automatically detect whether a terminal is color-capable or not, so when I run said program from within a non-color capable terminal (say M-x shell in (X)Emacs), color is automatically turned off.
I don't want to hardcode the program to detect TERM={emacs,dumb}.
I am thinking that termcap/terminfo should be able to help with this, but so far I've only managed to cobble together this (n)curses-using snippet of code, which fails badly when it can't find the terminal:
#include <stdlib.h>
#include <curses.h>
int main(void) {
int colors=0;
initscr();
start_color();
colors=has_colors() ? 1 : 0;
endwin();
printf(colors ? "YES\n" : "NO\n");
exit(0);
}
I.e. I get this:
$ gcc -Wall -lncurses -o hep hep.c
$ echo $TERM
xterm
$ ./hep
YES
$ export TERM=dumb
$ ./hep
NO
$ export TERM=emacs
$ ./hep
Error opening terminal: emacs.
$
which is... suboptimal.
A friend pointed me towards tput(1), and I cooked up this solution:
#!/bin/sh
# ack-wrapper - use tput to try and detect whether the terminal is
# color-capable, and call ack-grep accordingly.
OPTION='--nocolor'
COLORS=$(tput colors 2> /dev/null)
if [ $? = 0 ] && [ $COLORS -gt 2 ]; then
OPTION=''
fi
exec ack-grep $OPTION "$#"
which works for me. It would be great if I had a way to integrate it into ack, though.
You almost had it, except that you need to use the lower-level curses function setupterm instead of initscr. setupterm just performs enough initialization to read terminfo data, and if you pass in a pointer to an error result value (the last argument) it will return an error value instead of emitting error messages and exiting (the default behavior for initscr).
#include <stdlib.h>
#include <curses.h>
int main(void) {
char *term = getenv("TERM");
int erret = 0;
if (setupterm(NULL, 1, &erret) == ERR) {
char *errmsg = "unknown error";
switch (erret) {
case 1: errmsg = "terminal is hardcopy, cannot be used for curses applications"; break;
case 0: errmsg = "terminal could not be found, or not enough information for curses applications"; break;
case -1: errmsg = "terminfo entry could not be found"; break;
}
printf("Color support for terminal \"%s\" unknown (error %d: %s).\n", term, erret, errmsg);
exit(1);
}
bool colors = has_colors();
printf("Terminal \"%s\" %s colors.\n", term, colors ? "has" : "does not have");
return 0;
}
Additional information about using setupterm is available in the curs_terminfo(3X) man page (x-man-page://3x/curs_terminfo) and Writing Programs with NCURSES.
Look up the terminfo(5) entry for the terminal type and check the Co (max_colors) entry. That's how many colors the terminal supports.