Unhandled exception at 0x0FA6F6E0 (ucrtbased.dll). A read access violation at 0x00000000 has occurred

Question

This is my C++ code to data encryption. The code runs, but does not work correctly! I don't know what is wrong The debugger shows this error:

An unhandled exception at 0x0FA6F6E0 (ucrtbased.dll) in ConsoleApplication6.exe:
0xC0000005: A read access violation at 0x00000000 has occurred

Here is my code:

#include<iostream>
#include<conio.h>
#include<fstream>
#include<string.h>
#include<stdlib.h>
#include<math.h>
using namespace std;
void main(int argc, char **kluch)
{
    system("cls");
    cout << "Key: N+3" << kluch[1];
    ifstream in("C:\\Users\\s1mi\\source\\repos\\ConsoleApplication6\ConsoleApplication6\123\Input.txt");
    ofstream out("C:\\Users\\s1mi\\source\\repos\\ConsoleApplication6\ConsoleApplication6\123\Output.txt");
    if (!in)
    {
        cout << "\nThere is no filefor coding (Input.txt).";
        cout << "\n\nPres any key for exit.";
        _getch();
        exit(1);
    }
    char temp, buf = NULL;

    int n = strlen(kluch[1]);
    int j, i = 0;
    for (int k = 0; k < n; k++)
        while (!in.eof())
        {
            in.read((char*)&buf, sizeof(buf));
            if (buf == NULL)break;
            j = fmod(i, n);
            temp = buf ^ kluch[1][j];
            out.put(temp);
            i++;
            buf = NULL;
        }
    in.close();
    out.close();
    cout << "\nThe text is in a file Output.txt";
    _getch();
}

`"C:\\Users\\s1mi\\source\\repos\\ConsoleApplication6\ConsoleApplication6\123\Input.txt"` There seems to be inconsistency in your backslashes. — Drew Dormann, Nov 23 '21 at 21:07
Think about what `in.read((char*)&buf, sizeof(buf));` does. Does `buf` point to some storage that you could put the contents of the string into? — NathanOliver, Nov 23 '21 at 21:09
`void main` What compiler are you using? Plenty of things in this code are not C++. This seems to be "C with iostreams" — Drew Dormann, Nov 23 '21 at 21:09
Try allocating some space for buf: `char buf[128];` Then put `in.read(buf, sizeof(buf));`instead of what you have — edtheprogrammerguy, Nov 23 '21 at 21:10
Suggestion: Crank up the compiler's warning level and then resolve the warnings. This will eliminate several errors that aren't worth spending debugging time on. — user4581301, Nov 23 '21 at 21:10
The null pointer could be related to assuming that argc > 1 and accessing `kluch[1]` you should check argc and end the program if argc is less than 2 — drescherjm, Nov 23 '21 at 21:12
@edtheprogrammerguy @NathanOliver et al. `buf` is not a pointer, but a single character! He's reading one character at a time. The code is very misleading to read. — JDługosz, Nov 23 '21 at 21:20
`fmod` in an encryption program is a smoking gun. Never use floating point in a cryptographic algorithm. — Richard Critten, Nov 23 '21 at 21:34
Probably unrelated future bug: [Why is iostream::eof inside a loop condition (i.e. `while (!stream.eof())`) considered wrong?](https://stackoverflow.com/questions/5605125/why-is-iostreameof-inside-a-loop-condition-i-e-while-stream-eof-cons) — user4581301, Nov 23 '21 at 21:37

score 1 · Answer 1 · answered Nov 23 '21 at 21:18

Well, did you run it with a command-line argument as it expects? You are not checking the value of argc.

ugh, watch your step

char temp, buf = NULL;

in.read((char*)&buf, sizeof(buf));

if (buf == NULL)break;

This is confusing since NULL is a C macro for what C++ calls nullptr, and you have a single char. You should be using '\0' for the ASCII nul character.

Don't use NULL in C++. If you had written nullptr the compiler would have flagged this as an error.

This is confusing because the hasty reader will think that buf is supposed to be a pointer and you need to allocate memory for it.

So, false alarm there. :( It may be correct but makes the code much harder to read and understand (and review)

Why are you casting &buf (which would be type char*) to char*?

You say you saw behavior in the debugger. So, you should be able to just see where the error happened! You need to change your settings to "break on first pass exception" or something like that. That is, have the Visual Studio debugger break when an exception is thrown, rather than when it is not caught and already unwound the stack. Once you find this setting, that will make quick work of finding exactly where the problem lies. Just look up the stack view to get back to your own program code.

Unhandled exception at 0x0FA6F6E0 (ucrtbased.dll). A read access violation at 0x00000000 has occurred

1 Answers1

ugh, watch your step