When running the following command: sourceanalyzer -debug -b $build_id touchless make
I'm getting this error:
Compiling C++ myFile.C
[ERROR]: Translator execution failed. Please consult the Troubleshooting section of the User Manual.
Translator returned status 139:
“/usr/include/c++/4.3/atomicity.h”, line 51: warning identifier
“__sync_fetch_and_add” is undefined
{ return __sync_fetch_and_add(__mem, __val); }
“/usr/include/c++/4.3/atomicity.h”, line 55: warning identifier
“__sync_fetch_and_add” is undefined
{ __sync_fetch_and_add(__mem, __val); }
“/usr/include/c++/4.3/new”, line 95: warning: first parameter of allocation
Function must be of type “size_t”
Void* operator new(std::size_t) throw (std::bad_alloc);
“/usr/include/c++/4.3/new”, line 96: warning: first parameter of allocation
Function must be of type “size_t”
Void* operator new[](std::size_t) throw (std::bad_alloc);
“/usr/include/c++/4.3/new”, line 99: warning: first parameter of allocation
Function must be of type “size_t”
Void* operator new(std::size_t, const std::nothrow_t&) throw ();
“/usr/include/c++/4.3/new”, line 100: warning: first parameter of allocation
Function must be of type “size_t”
Void* operator new[](std::size_t, const std::nothrow_t&) throw ();
“/usr/include/c++/4.3/new”, line 105: warning: first parameter of allocation
Function must be of type “size_t”
Inline void* operator new(std::size_t, void* __p) throw (){ return __p; }
“/usr/include/c++/4.3/new”, line 105: warning: first parameter of allocation
Function must be of type “size_t”
Inline void* operator new[](std::size_t, void* __p) throw (){ return __p; }
“/opt/ilog51/views51/include/ilog/list.h”, line 77: warning: first parameter of allocation function must be of type “size_t”
IL_MLK_DECL();
“/opt/ilog51/views51/include/ilog/list.h”, line 110: warning: no appropriate operator delete is visible
{ e(); delete_first; _first; _first = _last 0; _length = 0; }
Furthermore, when uploading the FPR file to SSC, under Artifacts the status is: Error Processing. And when auditing issues, the ssc is unable to locate source files.
Any ideas about this issues ?
One idea is that the older gcc 4.3 (year 2008?) used compiler built-ins that were specific to GCC, while Fortify relies on Clang to translate the source code.
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html
Related
This is the Dart code I made to practice functions:
String sayHello(String name,int age,String country){
print("Hello im $name , $age year old, come from $country");
}
void main()
{
sayHello('king',22,'us');
}
And the error I am getting is:
Error compiling to JavaScript:
Info: Compiling with sound null safety
lib/main.dart:1:9:
Error: A non-null value must be returned since the return type 'String' doesn't allow null.
String sayHello(String name,int age,String country){
^
Error: Compilation failed.
I referenced lots of function grammar about Dart but it didn't work.
My compiler was DartPad. Can I know where is the wrong grammar in my code?
In Dart, this error message indicates that the function may return without a value, even though you declared the function to return a String value.
Just change the return type to void
void sayHello(String name,int age,String country){
print("Hello im $name , $age year old, come from $country");
}
The following dart code's expected output is the handle to the file explorer window but the output always comes out to be 0 even though the file explorer window does exist!
import 'package:ffi/ffi.dart';
import 'dart:ffi';
void main() {
DynamicLibrary dl = DynamicLibrary.open('user32.dll');
final func = dl.lookupFunction<
IntPtr Function(Pointer<Utf16>?, Pointer<Utf16>?),
int Function(Pointer<Utf16>?, Pointer<Utf16>?)
>('FindWindowA');
print(func(nullptr, 'File Explorer'.toNativeUtf16()));
}
I have ran the function FindWindowA in a c++ program and it has returned the exptected output with the same input values that are NULL and 'File Explorer'.
In dart using null throws the error Invalid argument(s): argument value for ':ffi_param1' is null; hence the use of nullptr
FindWindowA does not take pointers to UTF-16 strings. The A in FindWindowA stands for "ANSI", which is Microsoft's way of indicating that it uses strings with single-byte code units encoded in the system's local encoding. (This is also indicated by its signature, which takes LPCSTR arguments.)
If you want to pass UTF-16 strings (which in Microsoft Windows are considered "wide strings"), then use FindWindowW.
I am using clang's abstract syntax tree generation to generate an AST for some source files. It maps out normal functions great, however it trips up on some functions, mislabeling them as variable declarations. When it does this it waits for a semicolon to finish this declaration and so does not map out the rest of the source file following the problem function. Is there a way to make clang realize that it's a function definition, not a variable declaration?
I put a semicolon after the function definition and doing that makes clang ignore the contents of the function, but at least it generates nodes for the code following it in the source file. I'm using the prophy python interface to interact with clang in my scripts, but ran clang manually and found the same thing.
This is an example of a function that clang does map:
int killProcess(int pid)
{
int ret=1;
HANDLE pHandle;
if ((pHandle = OpenProcess(PROCESS_ALL_ACCESS,FALSE,pid)) != NULL)
if(!TerminateProcess(pHandle,0)) {
ret=0;
CloseHandle(pHandle);
}
return ret;
}
This is an example of a function which clang thinks is a variable declaration and ignores everything after it if there is no semicolon after the closing brace:
DWORD WINAPI listProcessesThread(LPVOID param)
{
char sendbuf[IRCLINE];
LPROC lproc = *((LPROC *)param);
LPROC *lprocp = (LPROC *)param;
lprocp->gotinfo = TRUE;
sprintf(sendbuf,"[PROC]: Listing processes:");
if (!lproc.silent) irc_privmsg(lproc.sock,lproc.chan,sendbuf,lproc.notice);
if (listProcesses(lproc.sock,lproc.chan,lproc.notice,NULL, FALSE, lproc.full) == 0)
sprintf(sendbuf,"[PROC]: Process list completed.");
else
sprintf(sendbuf,"[PROC]: Process list failed.");
if (!lproc.silent) irc_privmsg(lproc.sock, lproc.chan, sendbuf, lproc.notice);
addlog(sendbuf);
clearthread(lproc.threadnum);
ExitThread(0);
}
The expected results would be that clang knows that this is a function and generates a corresponding AST, however it doesn't. It constructs a VAR_DECL node with the spelling "WINAPI" instead of a "FUNCTION_DECL" node. The error it gives upon running "clang -cc1 -ast-dump processes2.cpp" is:
`-VarDecl 0x5625ad7ab2e0 col:7 invalid WINAPI 'int'
1 error generated.
At the end of its log. The abstract syntax tree up until this point is generated and displayed.
NB: I do not have WINAPI library installed because I am working on a Ubuntu machine.
I am a new learner in Clang and meet an odd bug.
My code is a simple case:
.....
static llvm::cl::OptionCategory MyToolCategory("");
.....
int main(int argc, const char **argv)
{
CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
ClangTool Tool(OptionsParser.getCompilations(),
OptionsParser.getSourcePathList());
tooling::MyFactory Factory;
Tool.run(newFrontendActionFactory(&Factory));
return 0;
}
but it report an very odd error when compile with clang++(my llvm&clang's version is 3.4):
ToolingTutorial.cpp:74:23: error: no matching constructor for initialization of 'clang::tooling::CommonOptionsParser'
CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/acsa-amd2/Documents/llvm-3.4/tools/clang/include/clang/Tooling/CommonOptionsParser.h:67:3: note: candidate constructor not
viable: no known conversion from 'llvm::cl::OptionCategory' to 'const char *' for 3rd argument
CommonOptionsParser(int &argc, const char **argv, const char *Overview = 0);
^
/home/acsa-amd2/Documents/llvm-3.4/tools/clang/include/clang/Tooling/CommonOptionsParser.h:61:7: note: candidate constructor
(the implicit move constructor) not viable: requires 1 argument, but 3 were provided
class CommonOptionsParser {
^
/home/acsa-amd2/Documents/llvm-3.4/tools/clang/include/clang/Tooling/CommonOptionsParser.h:61:7: note: candidate constructor
(the implicit copy constructor) not viable: requires 1 argument, but 3 were provided
1 error generated.
make: *** [ToolingTutorial.o] Error 1
it makes no sense that the constructor is no match and the compiler mistake 'llvm::cl::OptionCategory' for 'const char *' .
Did anyone meet this problem? Thanks!
In the latest LLVM14, CommonOptionsParser's construct functions are declared as protected or private. So, replace these functions with create(...).
llvm::Expected<clang::tooling::CommonOptionsParser> option = CommonOptionsParser::create(argc, argv, FindDeclCategory, llvm::cl::OneOrMore, FindDeclUsage);
auto files = option->getSourcePathList();
clang::tooling::ClangTool tool(option->getCompilations(), files);
return tool.run(clang::tooling::newFrontendActionFactory<DeclFindingAction>().get());
I had the same error in a tutorial, the error message says that there is something wrong with the last argument.
I have checked the official API (http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1CommonOptionsParser.html) and the example given seems to use the same pattern.
But I have also checked my source files (/usr/include/clang/Tooling/CommonOptionsParser.h on Arch) and the declaration of the constructor is not the same.
My clang version is 3.4. The next version is 3.5 and I think that the official documentation
is for the 3.5.
According to the documentation in the source file of the clang 3.4 the last argument seem to be optionnal and you can use:
CommonOptionsParser OptionsParser(argc, argv);
After that I had no errors during the compile time.
i try to integrate Lua in a embedded project using GCC on a Cortex-M4. i am able to load and run a Lua script, calling Lua functions from C, calling C functions from Lua. but the C program crashes (HardFault_Handler trap rises) when the given script passed as parameter in luaL_dostring() contains any Lua syntax errors.
here the relevant C code that crashes due to the syntax error in Lua:
//create Lua VM...
luaVm = lua_newstate(luaAlloc, NULL);
//load libraries...
luaopen_base(luaVm);
luaopen_math(luaVm);
luaopen_table(luaVm);
luaopen_string(luaVm);
//launch script...
luaL_dostring(luaVm, "function onTick()\n"
" locaal x = 7\n" //syntax error
"end\n"
"\n" );
when doing the same with correct Lua syntax, then it works:
luaL_dostring(luaVm, "function onTick()\n"
" local x = 7\n"
"end\n"
"\n" );
when debugging and stepping through luaL_dostring(), i can follow the Lua parsing line for line, and when reaching the line with the syntax error, then the C program crashes.
can anybody help? thanks.
have disabled setjmp/longjmp in Lua source code in the following way:
//#define LUAI_THROW(L,c) longjmp((c)->b, 1) //TODO oli4 orig
//#define LUAI_TRY(L,c,a) if (setjmp((c)->b) == 0) { a } //TODO oli4 orig
#define LUAI_THROW(L,c) while(1) //TODO oli4 special
#define LUAI_TRY(L,c,a) { a } //TODO oli4 special
...so there is no setjmp/longjmp used anymore, but i still have the crash :-(
must have another cause???
found the problem: it is the sprintf function called on Lua syntax error. in fact, on my platform sprintf seems not support floating point presentation. so i changed luaconf.h the following way, limiting the presentation to integer format.
//#define LUA_NUMBER_FMT "%.14g"
#define LUA_NUMBER_FMT "%d"
must have another cause???
Yes: you can't use Lua here.
Lua's error handling system is built on a framework of setjmp/longjump. You can't just make LUAI_THROW and LUAI_TRY do nothing. That means lua_error and all internal error handling stops working. Syntax errors are part of Lua's internal error handling.
If your C compiler doesn't provide proper support for the C standard library, then Lua is simply not going to be functional in that environment. You might try LuaJIT, but I doubt that will be any better.
#define LUAI_THROW(L,c) c->throwed = true
#define LUAI_TRY(L,c,a) \
__try { a } __except(filter()) { if ((c)->status == 0 && ((c)->throwed)) (c)->status = -1; }
#define luai_jmpbuf int /* dummy variable */
struct lua_longjmp {
struct lua_longjmp *previous;
luai_jmpbuf b;
volatile int status; /* error code */
bool throwed;
};
Works as expected even you build without C++ exceptions