Hello all,

Size calculation in memory allocation at line 63 would make sense if it was:

newLine = (int *)malloc(lineCount * sizeof(int) + sizeof(*newLine));

Agree?

newLine = (int *)malloc(lineCount * sizeof(int) * sizeof(*newLine));

??

Way too complicated and with unnecessary code. Here is a greatly simplified way to do it. Using strtok() you could parse a string that has more than one kind of deliminator, such as '\n' and '\t' and ',' and the space, these are typical of CVS files (exported XLS files).

int parseStringbyLines(char *buffer, char ***string) 
{
    char** lines = NULL;
    char* ptr;
    char *temp;
    int size = 0;
    if( buffer == NULL || *buffer == '\0' || string == NULL || *string != NULL)
        return 0;
    temp = strdup(buffer); // duplicate the string
    ptr = strtok(temp, "\n");
    while(ptr)
    {
        lines = realloc(lines, (size += 1) * sizeof(char*));
        lines[size-1] = strdup(ptr);
        ptr = strtok(NULL, "\n");
    }
    free(temp);
    *string = lines;
    return size;
}

strdup is nonstandard. Your realloc idiom is one to avoid.

>>Your realloc idiom is one to avoid.
Just standard C. When the first parameter is NULL realloc() acts like malloc().

>>strdup is nonstandard
You might be right. That function can easily be re-implemented for any compiler.

>>Your realloc idiom is one to avoid. Just standard C. When the first parameter is NULL realloc() acts like malloc().

*sigh*

lines = realloc(lines, (size += 1) * sizeof(char*));

On realloc failure a new pointer is made pointing to NULL and the original block is lost and not freed.

>>On realloc failure a new pointer is made pointing to NULL and the original block is lost and not freed.

If realloc() fails, then the program has much larger problems than a little memory leak, such as the entire program will, or is about, to crash due to lack of memory. And that could even extend to the entire operating system. Consequently, on modern computers with several gig ram I don't even worry about realloc() failing. If you are working with embedded systems that have very limited ram then that would be different. But not very many people are doing that.

>>If realloc() fails, then the program has much larger problems than a little memory leak, such as the entire program will, or is about, to crash due to lack of memory. And that could even extend to the entire operating system. Consequently, on modern computers with several gig ram I don't even worry about realloc() failing. If you are working with embedded systems that have very limited ram then that would be different. But not very many people are doing that.

Regardless of your excuses; it is bad programming.

>>Regardless of your excuses; it is bad programming.
Its not an excuse -- its a fact of reality. You can pretty-up the code all you want but when malloc() and realloc() fail the program's gonna crash, and good programming ain't going to help that one bit.

I'd hate to be maintaining code you've written.

You're like the Herb Schildt of Daniweb. :(

>>Its not an excuse -- its a fact of reality. You can pretty-up the code all you want but when malloc() and realloc() fail the program's gonna crash, and good programming ain't going to help that one bit.

Memory management in C is the utmost importance. Disregarding checking for proper returns of malloc() and realloc() is bad programming. Ignoring possible memory leaks is negligence. The failures of these standard functions are not always related to lack of memory, but rather failure of giving you the memory you want to use. If program crashes, it is because you have created a bad program.

I don't want to continue this discussion here because its hijacking the thread and not relevant to the topic of this thread.