I'm going to be getting in data from a file of my own making. This file will contain a printf format string and the parameters passed to it. I've already generated this code.
Now I want to do the reverse. Read format string and the parameters and pass it back to printf functions. Can I somehow generate the appropriate call stack or am I going to have to reparse the format string and send it to printf() piecemeal?
Edit
I know the risks with the printf functions. I understand that there are security vulnerabilities. These issues are non-issues as:
This is to be used in a debugging context. Not to be handled outside of that scope.
Executable that reads the file, is executed by the person who made the file.
The datafile created will be read by an executable that simply expands the file and is not accessible by a third party.
It has no access to writing anything to memory (%n is not valid).
Use Case
To compress a stream with minimal CPU overhead by tracking constantly repeating strings and replacing them with enumerations. All other data is saved as binary data, thus requiring only minimal processing instead of having to convert it to a large string every time.
Related
Is there any command in C++ that I can use as reference to save an array of numbers into a spesific file that I can access and call it as an array of numbers as well in the next day? I am working on a ton of numbers, the thing is I know how to input those numbers into array, but I just dont want to input all of them again and again everytime I access the program, so is there any chance to input them at one time only? what I find out there is to save the file into .txt file, which is if I call it later it will be a "text" data, and i cant use that numbers on my project.
Your terminology is non-standard, so I suspect you're having trouble understanding how to find answers.
C++ doesn't have "commands". The closest two things you might mean are keywords and functions. Keywords are integral to the language, but do very low level things, like break, return, for and while. Functions are collections of C++ statements that you can call as one unit. There are various libraries that contain related sets of functions. The most common library in C++ is the C++ standard library, which contains functions like std::fopen and std::puts which are useful when writing to files.
In addition to the library functions, there are functions you can write yourself. The advantage of those is that you can easily study and modify the contents of the function to achieve just what you want.
Since you use the term "reference", I gather you're looking for a function that you can read to modify for your own purposes.
In that case, check out this collection of code. You could make some modifications and wrap it in a function to do what you want. In particular, note the for loop with the out_file<< num_array[count]<<" "; statement for how to write to a file, and the second for loop with the in_file >> a; statement for how to read the file back.
save the numbers in csv file
http://www.cplusplus.com/forum/general/170845/
the reload the csv file
http://forums.codeguru.com/showthread.php?396459-Reading-CSV-file-into-an-array
It is more or less quite easy to serialize and deserialze data structures with common libraries like boost::serialize.
But there is an also common case where I simply do something like ( pseudo code ):
// receiver
NetworkInputStreamSerialzer stream;
while (1) // read new data objects from stream
{
stream & data;
}
As I expect the data package must already be received complete from the network socket. If only a part of the object can be read the deserialization will fail. Especially with large data sets TCP will fragment the data.
Is there a generic way to deal with this problem? I have not found any hints to this problem in the docs from boost::serialize.
As this problem is generic to any kind of streamed data, not only for TCP based streaming but also for files where one prog sends and another receives the data, there must be a general solution but I could not find anything about.
My question is not specialized to boost. I use it only as an example.
EDIT:
Maybe some more explanation to my wording of "fragmentation":
Any kind of data, independent of the size it produces in serialized format, can be fragmented in several packages while transferred via TCP or by writing it to any kind of file. There is no kind of "atomic" write and read operation which is supported from the OS neither the serialization libraries I know.
So if reading an int from a human readable format like XML or JSON I can get the problem that I read a "11" instead of "112" if the "2" is not in the stream or file in the moment I read from it. So writing the length of the following content in a human readable format is also not a solution, because the size information itself can be corrupt while the read occurs in the moment the content string is not complete in this moment.
[Note: I get a sense from your Q, that you want a better alternative for boost::serialization for your specific case. If this doesn't answer your Q, then let me know, I shall delete it.]
Recommending to use Google Protocol Buffers from my own practical experience. Below are few advantages:
It can be used on wire (TCP etc.)
Simple grammar to write the .proto file for composing your own
messages
Cross platform & available with multiple languages
Very efficient compared to JSON & XML
Generates header & source files for handy getter, setter, serialize,
deserialize & debugging purpose
Easy to serialize & deserialize -- store to & retrieve from file
The last point is bit tricky. While storing in a file, you may have to insert the length of the message first and while retrieving, you may have to first read that length & then use read() method to read the exact number of bytes.
Above same trick you may want to use while passing on TCP. In first couple of bytes, the length can be passed. Once the length is determined, you can always collect the remaining fragmented message.
I have read that getline behaves as an unformatted input function. Which I believe should allow it to be used on a binary file. Let's say for example that I've done this:
ofstream ouput("foo.txt", ios_base::binary);
const auto foo = "lorem ipsum";
output.write(foo, strlen(foo) + 1);
output.close();
ifstream input("foo.txt", ios_base::binary);
string bar;
getline(input, bar, '\0');
Is that breaking any rules? It seems to work fine, I think I've just traditionally seen arrays handled by writing the size and then writing the array.
No, it's not breaking any rules that I can see.
Yes, it's more common to write an array with a prefixed size, but using a delimiter to mark the end can work perfectly well also. The big difference is that (like with a text file) you have to read through data to find the next item. With a prefixed size, you can look at the size, and skip directly to the next item if you don't need the current one. Of course, you also need to ensure that if you're using something to mark the end of a field, that it can never occur inside the field (or come up with some way of detecting when it's inside a field, so you can read the rest of the field when it does).
Depending on the situation, that can mean (for example) using Unicode text. This gives you a lot of options for values that can't occur inside the text (because they aren't legal Unicode). That, on the other hand, would also mean that your "binary" file is really a text file, and has to follow some basic text-file rules to make sense.
Which is preferable depends on how likely it is that you'll want to read random pieces of the file rather than reading through it from beginning to end, as well as the difficulty (if any) of finding a unique delimiter and if you don't have one, the complexity of making the delimiter recognizable from data inside a field. If the data is only meaningful if written in order, then having to read it in order doesn't really pose a problem. If you can read individual pieces meaningfully, then being able to do so much more likely to be useful.
In the end, it comes down to a question of what you want out of your file being "binary'. In the typical case, all 'binary" really means is that what end of line markers that might be translated from a new-line character to (for example) a carriage-return/line-feed pair, won't be. Depending on the OS you're using, it might not even mean that much though--for example, on Linux, there's normally no difference between binary and text mode at all.
Well, there are no rules broken and you'll get away with that just fine, except that may miss the precision of reading binary from a stream object.
With binary input, you usually want to know how many characters were read successfully, which you can obtain afterwards with gcount()... Using std::getline will not reflect the bytes read in gcount().
Of cause, you can simply get such info from the size of the string you passed into std::getline. But the stream will no longer encapsulate the number of bytes you consumed in the last Unformatted Operation
I am making a very basic interpreter (using my own language) for the functions of set theory (union, intersection, etc.). I'm coding with C++ and currently doing my reading and parsing from .txt file. However, I'm trying to make it so code can be executed in a "command-by-command" way, without having the command window close. I'm hoping to be able to have multiple functions be read and performed one after another by using the carriage return.
Is there a way I can change my parser so that it will keep accepting commands/function instead of reading the entire .txt file at one time?
Generally, when "parsing" something, the idea is to read token at a time, and not really care about lines and other such things.
If your language is structured that way, you could just read your language as a stream, and when you see a call to a function (or whatever you want to call it), execute that function as you go along [assuming you don't compile to machine code that requires the entire thing to be compiled at once, of course - if that's the case, you're in for a bit of work...]
But if you want to read a line at a time, then use the istream& getline(istream&, std::string&) method. It reads a single line. You then parse that line and do whatever makes sense with the result of the parsing.
I am planning to build an Online Judge on the lines of CodeChef, TechGig, etc. Initially, I will be accepting solutions only in C/C++.
Have thought through a security model for the same, but my concern as of now is how to model the execution and testing part.
Method 1
The method that seems to be more popular is to redirect standard input to the executable and redirect standard output to a file, for example:
./submission.exe < input.txt > output.txt
Then compare the output.txt file with some solution.txt file character by character and report the results.
Method 2
A second approach that I have seen is not to allow the users to write main(). Instead, write a function that accepts some arguments in the form of strings and set a global variable as the output. For example:
//This variable should be set before returning from submissionAlgorithm()
char * output;
void submissionAlgorithm(char * input1, char * input2)
{
//Write your code here.
}
At each step, and for a test case to be executed, the function submissionAlgorithm() is repeatedly called and the output variable is checked for results.
Form an initial analysis I found that Method 2 would not only be secure (I would prevent all read and write access to the filesystem from the submitted code), but also make the execution of test cases faster (maybe?) since the computations of test results would occur in memory.
I would like to know if there is any reason as to why Method 1 would be preferred over Method 2.
P.S: Of course, I would be hosting the online judge engine on a Linux Server.
Don't take this wrong, but you will need to look at security from a much higher perspective. The problem will not be the input and output being written to a file, and that should not affect performance too much either. But you will need to manage submisions that can actually take down your process (in the second case) or the whole system (with calls to the OS to write to disk, acquire too much memory....)
Disclaimer I am by no means a security expert.