Re: Malloc code
- From: Robby <Robby@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 30 Dec 2007 13:29:04 -0800
Hello to both Davids! Thankyou for replying!
David Wil. , your right I can just free it in main since the pointer to that
allocation is passed back to main. Sorry!
2. This code may be clearer than before, but it is full of functions
that do nothing but call other functions, functions that have no
external effect, and local variables that are assigned but not used.
Since I wanted to be represent as precice as possible the code in my actual
project, I included all the functions involved, but they do include other
code which is not pertinant to my problem... I just included them in case
they would some how be the source of the problem which I now doubt it very
much!.... so thats why they are there. I mean you can just ignore them. If
you wish I can start a new post called "Malloc code 2" and exclude these
functions and some other non relevent stuff.
David Web. BAD_POINTER should of been atleast set to 0 in its
innitialization, but the only reason I included :
if(pCL_B==NULL)
{BAD_POINTER=1;}
in my code is to show that I am aware that I should check if the pointer is
valid. But for testing purposes with the debuger, I can see if the bointer is
null by simply hovering my cursor over pCL_B as it displays its value! So for
now its not of a great concern. The urgent concern is to understand why I
read junk in the for loop of the TCP_LOAD_MCB_X function. The code sample
that was posted is far from what will actually be done as a final product. I
understand your concern and I appreciate you pointing it out and its also
good constructive critisism for me or anyone else that reads this post. (for
beginers like me that is!).
But the code although prettier than before is still pretty horrible -
BAD_POINTER is set if an allocation fails but left unassigned if it
succeeds; and you take no notice if the malloc fails - you just dereference
the pointer anyway.
To paraphrase david's question 3: how are you looking at the variables?
You have most probably noticed that I was using an array called "xxx[12]" in
TCP_LOAD_MCB_X and I am assigning the values to the items of the strucutre
like this:
pMCB1[i].ENDOFCHAR = 2;
and then re-assigning the value of ENDOFCHAR to an item in the xxx array
like so:
xxx[k]= pMCB1[i].ENDOFCHAR; k++;
This is because the watch window in my compiler is not able to read the
contents of "pMCB1[i].ENDOFCHAR". This is a known issue to them and are
currently working on it. Therefore in my code (as you have probably noticed)
I assign the value to the structure's item and then to assure that it really
was assigned I check it via the xxx[] array. As soon as the compiler's
company come up with a fix, I will remove the xxx array in its entirety. I
know its sad, but I have no choice! So this is why I do this in my code.
k=0;
pMCB1[i].ENDOFCHAR = 2;
xxx[k]= pMCB1[i].ENDOFCHAR; k++;
pMCB1[i].A2 = 4;
xxx[k]= pMCB1[i].A2; k++;
pMCB1[i].A1 = 6;
xxx[k]= pMCB1[i].A1; k++;
pMCB1[i].A0 = 8;
xxx[k]= pMCB1[i].A0; k++;
pMCB1[i].LEADING_PIX = 10;
xxx[k]= pMCB1[i].LEADING_PIX; k++;
pMCB1[i].TRAILING_PIX = 12;
xxx[k]= pMCB1[i].TRAILING_PIX; k++;
pMCB1[i].CHARSPACING = 14;
xxx[k]= pMCB1[i].CHARSPACING; k++;
pMCB1[i].CHAR_TRSP = 16;
xxx[k]= pMCB1[i].CHAR_TRSP; k++;
pMCB1[i].mCHAR_BCOLOR = 18;
xxx[k]= pMCB1[i].mCHAR_BCOLOR; k++;
pMCB1[i].lCHAR_BCOLOR = 20;
xxx[k]= pMCB1[i].lCHAR_BCOLOR; k++;
pMCB1[i].mTEXT_COLOR = 22;
xxx[k]= pMCB1[i].mTEXT_COLOR; k++;
pMCB1[i].lTEXT_COLOR = 24;
xxx[k]= pMCB1[i].lTEXT_COLOR; //k++;
So when the TCP_LOAD_MCB_X function is finished assigning all the items in
every structure, I return the malloc pointer, since it was reccomended to me
that we must not loose the pointer.
Then I pass it back into the FETCH() function. In this function I declare
another array called xxx[] for the same reason I did in the TCP_LOAD_MCB_X
function.
I also do another malloc which assigns its pointer to pCL_B. Then I try to
read every item of the structures that were previously assigned in the
TCP_LOAD_MCB_X function.
So if I put:
pt[i].ENDOFCHAR;
in the watch window, my compiler cannot directly display its contents.
Therefore I assign every item of the structure to an item of the array called
xxx[]. And this is why I have this in the fetch() function:
for(i=0;i<11;i++)
{
xxx[0]= pt[i].ENDOFCHAR;
xxx[1]= pt[i].A2;
xxx[2]= pt[i].A1;
xxx[3]= pt[i].A0;
xxx[4]= pt[i].LEADING_PIX;
xxx[5]= pt[i].TRAILING_PIX;
xxx[6]= pt[i].CHARSPACING;
xxx[7]= pt[i].CHAR_TRSP;
xxx[8]= pt[i].mCHAR_BCOLOR;
xxx[9]= pt[i].lCHAR_BCOLOR;
xxx[10]= pt[i].mTEXT_COLOR;
xxx[11]= pt[i].mTEXT_COLOR;
} //<<< Break point here!
Putting a break point in the for loop shown above permits me to see a series
of 12 values contained in every structure. But some of the series are good
and some are not (Junk!)
When i = 0, I read: (error,4,6,8,10,12,14,16,18,20,22,24)
When i = 1, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 2, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 3, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 4, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 5, I read: (2,,4,6,8,30,128, 164,0,18,20,22,24) <<< wrong data!
When i = 6, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 7, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 8, I read: (2,11,232,8,14,16,14,16,18,20,22,24) << wrong data!
When i = 9, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 10, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When I should read:
When i = 0, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 1, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 2, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 3, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 4, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 5, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 6, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 7, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 8, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 9, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
When i = 10, I read: (2,4,6,8,10,12,14,16,18,20,22,24)
and oops! I just tried something!
for(i=0;i<12;i++) instead of: for(i=0;i<11;i++)
and what the hell is the 176 doing there!
pMCB1 = malloc(176*(sizeof(struct MCB)));
//This allocates 2.112 KBytes, I only have 1.5Kbytes!
it should be:
pMCB1 = malloc(11*(sizeof(struct MCB)));
!!!!!!!!!!and it works!
That's it folks, I need a vacation!
C requires a vigilant mind and I am too tired! An infinate thankyou for your
support, I must admit, what gave it away was:
and it isn't immediately obvious
why you should see junk (as long as you're looking at variables after they
have been assigned).
Thankyou very much guys for your support.
Happy new year to all!
--
Best regards
Robert
"David Wilkinson" wrote:
Robby wrote:.
Hello,
David is right when he said:
They do this by writing well-structured programs
which are straightforward to debug, not by writing programs which are almost
impossible to debug, and being some kind of magician when they try to debug
them. The result is that the magician you want is probably not available.
Which is why I have further reduced the code sample and oddly enough even
with not declaring any global variables, I still get junk. David, I have
nothing against whatever you have said in your previous posts. However, I am
just trying to understand a little about why two mallocs declarations don't
do what their supposed to do... that is allocate the right data in the right
memory area. I can relate to your anger towards me. No offense taken my
freind.
Anyhow, if any help out there, I would really need it! Quite discouraged!
Here is a much clearer and easier to understand piece of code.
<snip>
That's it!
The for loop in fetch(), sometimes displays junk. I am supposed to read
(2,4,6,8,10,12,14,16,18,20,22,24) 11 times and thats not what I read!
And if pMCB1 is not declared global, then how do I free it when comming out
of fetch(); ?
Please accept that the malloc for the pCL_B pointer must reside in fetch()
as shown above.
Robby:
1. If you must top-post, please trim previous replies.
2. This code may be clearer than before, but it is full of functions
that do nothing but call other functions, functions that have no
external effect, and local variables that are assigned but not used. Try
to go through the code and examine the purpose of each line in the
context of the example. Also make sure each function has a purpose
(returns information to the caller).
3. What do you mean by "sometimes displays junk"?
4. In response to your specific question, why not free the memory in main?
int main()
{
struct MCB *px;
px = (struct MCB *) TCP_CONFIG_GMM();
LCD_PAINTSCREEN(px);
free(px);
return 0;
}
5. Note that main() should return int.
--
David Wilkinson
Visual C++ MVP
- Follow-Ups:
- Re: Malloc code
- From: David Webber
- Re: Malloc code
- From: David Wilkinson
- Re: Malloc code
- References:
- Malloc code
- From: Robby
- RE: Malloc code
- From: Robby
- Re: Malloc code
- From: David Wilkinson
- Malloc code
- Prev by Date: Re: MSDN volatile sample
- Next by Date: Re: Double-Checked Locking pattern issue
- Previous by thread: Re: Malloc code
- Next by thread: Re: Malloc code
- Index(es):
Relevant Pages
|