I'm using the Clang C++ API. As the API does not use smart pointers correctly, I've struggled with ownership. I stomped on all the issues I found so far on my own, but this one is vexing me. When the code executes, I get an access violation. I'm fairly certain it's a double delete, but since the documentation is nonexistent, I've got little idea where to look. Fortunately, the reproducing program is rather short. Any suggestions?
#define _SCL_SECURE_NO_WARNINGS
#pragma warning(push, 0)
#include <clang/CodeGen/CodeGenAction.h>
#include <clang/Frontend/CompilerInstance.h>
#include <clang/Sema/Lookup.h>
#include <clang/Lex/Preprocessor.h>
#include <clang/AST/ASTContext.h>
#include <clang/AST/Mangle.h>
#include <clang/Frontend/TextDiagnosticPrinter.h>
#include <clang/Basic/TargetInfo.h>
#include <clang/Sema/Sema.h>
#include <clang/Sema/SemaConsumer.h>
#include <clang/Sema/CodeCompleteConsumer.h>
#include <llvm/LLVMContext.h>
#include <llvm/Support/DataTypes.h>
#include <llvm/Module.h>
#include <llvm/Support/Host.h>
#pragma warning(pop)
#include <string>
#include <iostream>
int main(int argc, char* argv[])
{
llvm::LLVMContext c;
llvm::Module m("", c);
clang::EmitLLVMOnlyAction emit(&c);
emit.setLinkModule(&m);
clang::CompilerInstance CI;
std::string errors;
llvm::raw_string_ostream error_stream(errors);
clang::DiagnosticOptions diagopts;
clang::TextDiagnosticPrinter printer(error_stream, &diagopts);
llvm::IntrusiveRefCntPtr<clang::DiagnosticIDs> diagids(new clang::DiagnosticIDs);
clang::DiagnosticsEngine engine(diagids, &diagopts, &printer, false);
CI.setDiagnostics(&engine);
CI.createFileManager();
CI.createSourceManager(CI.getFileManager());
llvm::raw_null_ostream empty;
clang::PrintingCodeCompleteConsumer print(CodeCompleteOptions(), empty);
clang::TargetOptions target;
target.Triple = llvm::sys::getDefaultTargetTriple();
CI.setTarget(clang::TargetInfo::CreateTargetInfo(engine, &target));
CI.createPreprocessor();
CI.createASTContext();
clang::SemaConsumer* cons = new clang::SemaConsumer();
CI.setASTConsumer(cons);
CI.createSema(clang::TranslationUnitKind::TU_Complete, &print);
cons->InitializeSema(CI.getSema());
clang::FrontendInputFile f("header", clang::InputKind::IK_CXX, true);
emit.BeginSourceFile(CI, f);
emit.Execute();
emit.EndSourceFile();
emit.takeModule();
clang::LookupResult lr(CI.getSema(), clang::DeclarationName(CI.getPreprocessor().getIdentifierInfo("function")), clang::SourceLocation(), clang::Sema::LookupNameKind::LookupOrdinaryName);
auto result = CI.getSema().LookupName(lr, CI.getSema().TUScope);
std::string temp;
llvm::raw_string_ostream out(temp);
CI.getASTContext().createMangleContext()->mangleName(lr.getFoundDecl(), out);
auto fun = m.getFunction(temp);
std::cout << fun->getName().str();
return 0;
}
Edit: Also, did I mention that if I change it so that the file actually exists, even if it's a trivial program, Clang fails with an access violation whilst executing the action, even before the previous one in EndSourceFile. Whyyyyyy.
I eventually solved this by skipping the entire Frontend, as that's mostly where all of the dodgy ownership lies, and simply calling the functions I need myself.
Related
my question is pretty simple but I can't seem to find it out.
I want to know what libary to include when using stoi. I was using atoi and it works fine with
#include <iostream>
#include <string>
#include <stdlib.h>
using namespace std;
but I get "stoi not declared" when I run with stoi. Thanks
You need to #include <string> and use a compiler that understands C++11. Minimal example:
#include <string>
#include <cassert>
int main()
{
std::string example = "1234";
int i = std::stoi(example);
assert(i == 1234);
return 0;
}
Compile, for example, with g++ -std=c++11.
I'm writing a project in Vulkan and it compiles and runs fine. The code is the same as it always was, but after some software updates (Steam, Visual Studio, etc.) an error has been popping up.
I mention steam as that was causing a separate runtime error. The same error as here: https://www.reddit.com/r/vulkan/comments/8ybq6f/need_some_help_debugging/e29qptx/
Anyway, the line:
const std::vector<const char*> validationLayers = { "VK_LAYER_LUNARG_standard_validation" };
and ones like that using std::vector and std::array give me the error: Ambiguous symbol 'const std::vector<const char*>'
My includes and defines are as follows:
#define GLFW_INCLUDE_VULKAN
#define GLM_FORCE_RADIANS
#define STB_IMAGE_IMPLEMENTATION
#include <glfw3.h>
#include <glm.hpp>
#include <gtc/matrix_transform.hpp>
#include <stb/stb_image.h>
#include <iostream>
#include <stdexcept>
#include <functional>
#include <vector>
#include <set>
#include <algorithm>
#include <fstream>
#include <string>
#include <array>
#include <chrono>
#ifdef NDEBUG
const bool enableValidationLayers = false;
#else
const bool enableValidationLayers = true;
#endif
So if there's a way to suppress this particular error highlighting, or if there is a genuine conflict, I'd love to know where it is / how to do it.
Like I say, it still runs fine, but it is annoying to look at my scroll bar and see a bunch of red markers that would normally indicate my program not compiling.
This turned out to be an issue with the version of ReSharper I was using. It is also reported here: https://resharper-support.jetbrains.com/hc/en-us/community/posts/360000430159-Intellisense-issue-with-C-17-standard?flash_digest=bbcceaf4d5a9c12c634a59aba32fc2143a325734
The solution is to turn it off or upgrade to R++ 2018.2
Intro
First of all, I would like to say that I have read through the previous answers for this type of question, including this excellently written one.
However, I do not understand enough about C++ to be able to use the more "advanced" fixes.
I have ensured that the right type of console has been selected (Console (/SUBSYSTEM:CONSOLE) for those interested), and have the required imports with the possible exception of an IDL mentioned somewhere (that falls into the lack of understanding category).
If this is a duplicate, I would be more than happy to use the post I duplicated, but I have not been able to find anything that can help someone of my skill level.
Technical Information
IDE: Visual Studio
Platform: Windows
Code
headers.h
#pragma once
#include <stdio.h>
#include <iostream>
#include <string>
#include <windows.h>
#include <Shobjidl.h>
#include <time.h>
#include <stdlib.h>
#include <tchar.h>
main.cpp
#include "headers.h"
using namespace std;
int main() {
string x = "C://Users/student/Desktop/i-should-buy-a-boat.jpg";
x.c_str();
wstring tempx = std::wstring(x.begin(), x.end());
LPCWSTR sw = tempx.c_str();
HRESULT SetWallpaper(
LPCWSTR monitorID,
LPCWSTR wallpaper
);
SetWallpaper(NULL, sw);
}
SetWallpaper() is not a standalone function exported by the Win32 API. It is a method of the IDesktopWallpaper interface (see here).
So you need to use code that is more like this instead:
#include "headers.h"
int main()
{
std::wstring x = L"C:\\Users\\student\\Desktop\\i-should-buy-a-boat.jpg";
CoInitialize(NULL);
IDesktopWallpaper *p;
if (SUCCEEDED(CoCreateInstance(__uuidof(DesktopWallpaper), 0, CLSCTX_LOCAL_SERVER, __uuidof(IDesktopWallpaper), (void**)&p)))
{
p->SetWallpaper(NULL, x.c_str());
p->Release();
}
CoUninitialize();
return 0;
}
I am trying to derive key from password and want to generate randomly the salt(I dont know what size it should be for SHA-256 and does this matter like the IV in AES256, where it should be 128 bit,give a hint if someone know) with AutoSeededRandomPool but exception is cought
RandomNumberGenerator:GenerateBlock Not Implemented
I am using crypto++ 5.6.3rc5 with QT 5.5.1 and /MD release mode, this may be a bug, or unfinished work of someone.
#include <QCoreApplication>
#include <sha.h>
#include <base64.h>
#include <iostream>
#include <string>
#include <pwdbased.h>
#include <cstdio>
#include <iostream>
#include <osrng.h>
using CryptoPP::AutoSeededRandomPool;
#include <iostream>
using std::cout;
using std::cerr;
using std::endl;
#include <string>
using std::string;
#include <cstdlib>
using std::exit;
#include <cryptlib.h>
using CryptoPP::Exception;
#include <hex.h>
using CryptoPP::HexEncoder;
using CryptoPP::HexDecoder;
#include <filters.h>
using CryptoPP::StringSink;
//#include <stdlib.h>
#include <time.h>
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
try
{
AutoSeededRandomPool rng;
byte salt[16*8];
rng.GenerateBlock(salt, 16*8);
byte password[] ="password";
size_t plen = strlen((const char*)password);
size_t slen = strlen((const char*)salt);
int c = 1;
byte derived[32];
CryptoPP::PKCS5_PBKDF2_HMAC<CryptoPP::SHA256> pbkdf2;
pbkdf2.DeriveKey(derived, sizeof(derived), 0, password, plen, salt, slen, c);
string result;
HexEncoder encoder(new StringSink(result));
encoder.Put(derived, sizeof(derived));
encoder.MessageEnd();
cout << "Derived: " << result << endl;
}
catch (const Exception& ex) {
cerr << ex.what() << endl;
}
return a.exec();
}
Crypto++ 5.6.3rc5 GenerateBlock Not Implemented
...
You can read the history on the change at Crash in RandomNumberGenerator::GenerateWord32 due to stack recursion. The change was eventually backed out.
It was fixed in RC6, but it has not been announced yet. There's a quasi-pre-RC6 at Crypto++ 5.6.3 Files. But as soon as it is announced, then its set in stone and will not be changed.
Right now, RC6 is undergoing minor changes due to Cygwin, MinGW and C++11 on Debian Unstable. The changes are not too bad, but testing them is painful. Some of the scripts take half a day to run under emulated platforms, like S/390x.
If you want to side step the issue and avoid the download of pre-RC6, then you can use one of the following generators. They call GenerateIntoBufferedTransformation:
AutoSeededX917RNG< AES >
X917RNG
RandomPool
Or, you can use OS_GenerateRandomBlock to draw directly from the OS's pool.
Or, you can remove the code that throws. Open cryptlib.h, find RandomNumberGenerator, remove the #if 0/#endif guarding the old code and delete the throw.
Also see RandomNumberGenerator on the Crypto++ wiki.
I'm current building an application in which I have a log function that is accessible in most of my classes which was declared as below:
FileHandler.h
#ifndef FILEHANDLER_H
#define FILEHANDLER_H
#pragma once
#include <SDL.h>
#include <string>
#include <iostream>
#include <fstream>
#include <sstream>
#include <vector>
#include <algorithm>
#include <cctype>
//Include to allow logging
#include "log.h"
class fileHandler
{
public:
fileHandler();
virtual ~fileHandler();
void WriteToFile(const std::string& filename, std::string textToWrite);
std::vector<std::string> ReadFromFile(const std::string& filename);
std::string& TrimString(std::string& stringToTrim);
protected:
private:
class log logHandler;
std::vector<std::string> blockOfText;
std::string currentLine;
};
#endif // FILEHANDLER_H
Log.h
#ifndef LOG_H
#define LOG_H
#pragma once
#include <SDL.h>
#include <string.h>
#include <iostream>
#include <sstream>
#include <fstream>
#include <time.h>
class log
{
public:
log();
virtual ~log();
void static WriteToConsole(std::string textToWrite);
void WriteToLogFile(std::string textToWrite);
protected:
private:
};
#endif // LOG_H
This worked fine for a long time and then I wanted to include another function elsewhere in my application that was only compatible with C++11 so I told the compiler to compile to these standards. I was then receiving an error on "log logHandler" saying log is not a declared name.
I was able to resolve the problem by changing the line to
class log logHandler;
I was wondering if anybody could tell me what has changed between C++03 and C++11 that required me to do this?
EDIT: Included all relevant code to make question more complete.
You don't show your real code (missing ; at the end of the class declaration, no #endif), but chances are that your problem is somehow related to std::log, which has received a new overload in C++11, in combination with a using namespace std somewhere in your code.
Note that the new overload is probably irrelevant to the problem at hand; the real reason may very well be a change somewhere in your compiler's standard-library implementation causing an internal #include <cmath>. This means that even in C++03, your code was only working by sheer coincidence, and a conforming C++03 compiler was always allowed to reject it.
Here is an example program which may reproduce your problem:
#include <cmath>
using namespace std;
struct log
{
};
int main()
{
// log l; // does not compile
struct log l; // compiles
}
Nothing has changed about how the code you posted is treated.
What I suspect is, that you somewhere have an
#include <cmath>
And below that, somewhere else
using namespace std;
This causes your compiler to not be able to unambiguously resolve the name log, since there is std::log (a function) and your class log.
By explicitly stating class log, you tell the compiler that you are referring to the class.