1

The problem here resides with reading the char * nv, which basically points to 0xCCCCCCCC with the error Error reading characters of string

Already tried other fixes. There are more steps to this code but this is the simplified, overly-specific version:

char** splitStr(char* str, char separator, int sizeRet) {
    char ** tot = new char *[sizeRet];
    char * sep = new char[2];
    sep[0] = separator;
    sep[1] = '\0';
    char * nv;
    nv = strtok(str, sep);
    int i = 0;
    while (nv != NULL) {
        tot[i] = nv;
        nv = strtok(NULL, sep);
        i++;
    }
    return tot;
}

Update

The code works in an online compiler perfectly. It doesn't work in Visual Studio 2017 for some odd reason. Will try eliminating some folders from the framework I have to use, and try again.

Swailwort
  • 19
  • 2
  • 1
    Is there a reason you don't do `char sep[2];` instead of allocating on the heap? (plus you're leaking since you've forgotten to delete it) – scohe001 Apr 18 '18 at 23:31
  • Why oh why would you do this: `char * sep = new char[2];`? Of course the obvious has happened: you forgot to delete it and have a memory leak. You might need to show how you call `splitStr()`. – John3136 Apr 18 '18 at 23:32
  • 1
    You should never use strtok in C++, or in C, really. –  Apr 18 '18 at 23:36
  • I had to create the auxiliar sep[2] to create a constant char for strtok, which is, on itself, a terrible function – Swailwort Apr 18 '18 at 23:45
  • John, I had to create it to "convert" the char separator to a constant char, in order to use it inside the strtok. I certainly forgot to delete it, but does it really affect the execution of the next sequence of code? – Swailwort Apr 18 '18 at 23:48
  • 1
    `const char sep[] = { separator, '\0' };` – Barmar Apr 19 '18 at 00:02
  • What problem are you having with the code? The only issue I can see is that there's no way to tell where the last token is in the returned array. – Barmar Apr 19 '18 at 00:04
  • You allocate `sizeRet` elements for `tot`, but nothing in your loop restricts it to accessing only `sizeRet` elements. You might have a buffer overrun. – Igor Tandetnik Apr 19 '18 at 00:04
  • @IgorTandetnik We could say that's the caller's problem, they should ensure that `sizeRet` is large enough (e.g. at least `strlen(str)`) – Barmar Apr 19 '18 at 00:05
  • @Barmar We could say that, yes. But perhaps the problem the OP is having is precisely that the caller (conspicuously absent from the question) failed to ensure that. – Igor Tandetnik Apr 19 '18 at 00:08
  • `Error reading characters of string` doesn't sound like a standard error, where does that come from? – Barmar Apr 19 '18 at 00:11
  • perhaps the `Error reading characters of string` is related to the used IDE ? https://stackoverflow.com/questions/18946459/error-reading-characters-of-string – Rann Lifshitz Apr 19 '18 at 00:19
  • i am running the code in question on an onlice c++ compiler, and am only getting seg faults at the first strtok. No mention of `Error reading characters of string` – Rann Lifshitz Apr 19 '18 at 00:21
  • Using Visual Studio, the problem was not with the Separator, and sizeRet is in fact large enough according to the rest of the code which is specific to calculating it. The problem is specifically when reading the string to which I apply strtok; oddly enough, If I decide to allocate memory for it, it only returns garbage. It's weird – Swailwort Apr 19 '18 at 00:46
  • This function works for me if `str` is a real character array (`char str[] = "a string";`), but it segfaults if I pass a string literal as `str`. This is because `strtok` [writes to the string each time it finds a token](http://en.cppreference.com/w/c/string/byte/strtok). – Jack C. Apr 19 '18 at 02:36

1 Answers1

0

Well, the problem is solved. Decided to stop usign strtok and doind the good old iterative runs avoiding the separators and Voila, it works perfectly. I hate Visual Studio though

Swailwort
  • 19
  • 2