Thanks Jim.
No, the question has been completely distorted now, and to prevent further confusion this is a summery.
*Summery*
I tried testing pointers as the first helpful reply had insisted, but I was unsure because of the failed response, and had decided to figure out what the problem was, and blamed it on the variable being a double pointer. The test case failed because of a horrible testing environment, the variable manipulation insisted strrchr() be used, and the test "sizeof(ptr)==strlen()" failed even though it logically made sense. Because of this, I tested ALL instances just to find what I thought was the right method so I did the following.
if(sizeof(Ptr) ==strlen()+1)
if(sizeof(Ptr) ==strlen()+0)
if(sizeof(*Ptr) ==strlen()+1)
if(sizeof(*Ptr) ==strlen()+0)
but, this is AFTER the allocation of the ptr. All of them failed the test but one, so I took the success of the test, and blindly applied it to the real issue. The real issue CONTINUED to fail, even using the same successful method in the test. This confused me beyond belief, so I requested help.
I stopped trusting my methods as I knew the code worked when I had no checks applied. So, after doubting my own knowledge, ab5000 put me back on track telling me that my test case "if(sizeof(*Ptr) == strlen())"
may have worked for bypassing the check in that case, but was not what I was intending to do. So, like he stated, I went back and used the same method as had failed before and used "if(sizeof(Ptr) == strlen())" and it still gave me the error "DIR FILE, RESTRICTED FROM MEMORY. HEAP CLOSED. :1".
Since I knew that ab5000 had agreed with my original belief, I was able to corner the problem even further. I tested the first loop instance and yes, it returned sizeof(file
)==strlen() *PASSES*, the string pointed to was "Cool\0" the size of the string, and allocation size was correct, they had to be if realloc did not return NULL, because I specifically told it how many blocks to gather.
Both sizeof(ptr) and strlen() returned 4 so they passed, but I keep getting that same error message, so somewhere in there, it messes up. When ANY allocation fails to successfully allocate, or even gets NULL returned, the error line is printed to the screen, and ALL other allocation is freed appropriately in reverse order. But, NULL is tested first, so if the value returned was NULL, it would print "DIR FILE, RESTRICTED FROM MEMORY. HEAP CLOSED. :2" Notice the error return has "2" at the end. My situation says that the return is NOT NULL because I nested the statements in
Code: Select all
file[i]=realloc(file[i],strlen(story)+1);
if (file[i] != NULL)
{
if(sizeof(file[i]) != strlen(story))
{
print ("DIR FILE, RESTRICTED FROM MEMORY. HEAP CLOSED. :1");
}
}
else
{
print ("DIR FILE, RESTRICTED FROM MEMORY. HEAP CLOSED. :2");
}
I'm trying to give cases without making anyone read those large code blocks, but like the code I JUST posted above this sentence, "IT IS NOT, NOT, NOT! THE ACTUAL CODE" ignore syntax errors, and short abbreviations. The question has been pinpointed by Raphael, that maybe the size cannot be compared in all cases, but... in this case, it is "NOT" NULL, because the error string has the 1 on the end instead of a 2.
This means something else is wrong, and dying to try to figure it out, either the loop stretches out of bounds and reads a pointer that is not valid, a pointer is not properly allocated, or like Raphael has said, the variable cannot be checked using this method. I hope this isn't the case, but I seriously think the pseudo code abbreviations misinformed Raphael of the actual code's problem, or I'd like to know that if sizeof won't return the proper value in all cases, why is that, because without knowing why, I can't prevent this from happening again.
I've drawn this out on paper, aluminum foil, and finally a whiteboard for larger representation, and have not yet come to see a problem in the overall algorithm that starts, or connects the initiation to the browse function, nor have I found an error in the browse function. The only actual code representations of the error are in those large 3 code sections of the original post. I can remove the * that de-references the pointer that is being check RIGHT THERE WHERE THE ERROR CONDITION ACTIVATES, but that won't help, as I've already done that and tested it working as the sizeof does return the correct value to match the string length used to calculate the allocation size. I don't care about the rest of the function, just that ONE part. You can ignore the header too, it's just there so that you can see why things were allocated as they were if you feel as I do, that the problem could very well be ANYTHING that is so minor it's overlooked.
I tested the sizeof(file[]) data and strlen() with
Code: Select all
folder->bank_dir->c->file[counter] = realloc( folder->bank_dir->c->file[counter], strlen( fldrt->d_name )+1);//method 1
//free(folder->bank_dir->c->file[counter]);folder->bank_dir->c->file[counter]=malloc(strlen( fldrt->d_name )+1);//method 2
if(folder->bank_dir->c->file[counter] != DEAD)
{
if( sizeof(folder->bank_dir->c->file[counter]) != strlen(fldrt->d_name) )
{
Set_Window_Notice(folder,"DIR FILE, RESTRICTED FROM MEMORY. HEAP CLOSED. :1");Terminate_Directory_Bank(folder); return 0;//ptr & +1 :failed; ptr & +0 :failed;
}
/*//TEST
unsigned int num[4];
num[0] = sizeof(folder->bank_dir->c->file[counter]);
num[1] = strlen(folder->bank_dir->c->file[counter]);
num[2] = sizeof(fldrt->d_name);
num[3] = strlen(fldrt->d_name);
char research1[255];
char research2[255];
sprintf(research1,"%s byte size:%d; string size:%d;",folder->bank_dir->c->file[counter], num[0],num[1]);
sprintf(research2,"%s byte size:%d; string size:%d;", fldrt->d_name, num[2],num[3]);
print(0,0,research1,rgb(255,0,0));print(0,10,research2,rgb(255,0,0));flipScreen();while(1){};*/
