Re: Simple question about headers and malloc!

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hello Ben,

If xxx.c uses functions from yyy.c, then xxx.c should include yyy.h. Once
it does you will probably find that main.c no longer needs to.

The example I showed innitially was what I was doing to try to solve the
problem, but that didn't work. :-(

A simplified version of how I have it now is:

==========================================
#include <xxx.c>

int main()
{
//...some code !
//Calls functions in xxx.c
}

===========xxx.h
....some declarations
==============
===========xxx.c
#include <xxx.h>
#include <yyy.c>
....some code
//Calls functions in yyy.c
==============

===========yyy.h
....some declarations
==============

===========yyy.c
#include <yyy.h>
....some code
==============
===========================================

But I don't think that it has anything to do with this. Alot of effort is
being put on trying to water down a sample version where I could demonstrate
that I am getting junk when reading the first memory allocated by malloc. But
everytime I take out code and test again it bombs dramatically or it
gracefully works, and so this is why I am not posting any actual code since I
can't put my finger on it. When it gracefully works, is when I rellocate the
two malloc statements so they are in the same function and everything is well
then!(View this in commented line of Function1). But if I try to execute a
function with one malloc statement and then execute a different function with
the second malloc statement, thats it, junk!

Also, I know that David says:

Well, I'm afraid you should reorientate your "likes" a bit, for that is the
way it is done. You allocate memory, and you hang onto the pointer (not
another one in another file with the same name) until you free the memory.
Passing it back to the function which "owns it" is the way this is done.

But I don't know how to apply this to my program as you will see why:

Lets say, I declare two structures and several pointers of the type of
these structures in yyy.h as so:

=============================================yyy.h
struct MCB{
int A0; //LSB OF MESSAGE ADDRESS IN PAR FLASH
int A1; //MIDSB OF MESSAGE ADDRESS IN PAR FLASH
int A2; //MSB OF MESSAGE ADDRESS IN PAR FLASH
};

//Declare a pointer of type "struct MCB"
struct MCB* pMCB1;
struct MCB* pMCB2;
struct MCB* pMCB3;

struct CL_B{
int BYTE1;
int BYTE2;
};

//Declare a pointer of type "struct CL_B"
struct CL_B* pCL_B;
=================================================

shouldn't I be able to allocate memory in two steps, where each step is done
in a different function using malloc this way:

==================================main.c
#include xxx.c
int main()
{
configure();
}
=====================================

==================================xxx.c
Configure()
{
funtion1();
funtion2(int j);
}
=====================================

==================================yyy.c
function1()
{
struct MCB* px;
int i;
px = (struct MCB *)SizeMCB_X(0);
//pCL_B = malloc(15*(sizeof(struct CL_B))); //If 2nd malloc here, then okay!

//Fill the arrays of structures!
for(i=0;i<11;i++){
px[i].A0 = 10;
px[i].A0 = 10;
px[i].A0 = 10;}

}


function2(int j)
{
xxx[3];
struct MCB *px;
pCL_B = malloc(15*(sizeof(struct CL_B)));

switch(j)
{case 0: px = pMCB1;break;
case 1: px = pMCB2;break;}

//Read data from first allocation! I read junk when I view contents of
xxx[0],
//xxx[1], xxx[2] ?????

xxx[0]= px[0].A0;
xxx[1]= px[0].A1;
xxx[2]= px[0].A2;
}


void * SizeMCB_X(int m)
{
switch(m)
{case 0:
pMCB1 = malloc(11*(sizeof(struct MCB)));
return pMCB1;
break;
case 1:
pMCB2 = malloc(11*(sizeof(struct MCB)));
return pMCB2;
break;
//and so forth!
}

}
==============================================

You see, the mallocs have to be called *conditinally* within yyy.c because
its not everytime I need to allocate memory. Some may suggest to just
allocate them all at the begining and thats it. But I can't really do this
because sometimes I need MCB1 only or sometimes I may need MCB1 and MCB3 and
so forth....You see, the more memory is allocated, I am afraid I will loose
speed! So I allocate as I require within the functions. In any case
regardless how many allocations I need to do at one time, its just that what
I am doing gives me junk readings and I try and try and feel discouraged.

Which takes me back to:

Passing it back to the function which "owns it" is the way this is done.

In my case, function1 and function2 owns the pointers to the mallocs,
right?. So is David suggesting I pass these pointers back to new pointers in
xxx.c or main and then pass them back in when I fetch function2 ???

All right everybody, please go easy on me ! I know all the stuff about
getting more books and reading more on the subject, but I do read C books (I
even have a book called, programmers bible of C and it doesn't even show what
should be done in this case!) its just that I don't find the answer to an
alternative coding method in order to get rid of this bug. :)

I would *really* appreciate hearing from anyone who can help me!

Thanks!

--
Best regards
Robert


"Ben Voigt [C++ MVP]" wrote:

#include <yyy.h> //Is this okay?
#include <xxx.c>

Have you really included xxx.c in another .c file?

This certainly looks like the issue, however Robby is using an embedded
compiler that might not support linking multiple translation units (though
that would be surprising).


int main()
{
//...some code !
//Calls functions in xxx.c
}

===========xxx.h
...some declarations
==============
===========xxx.c
#include <xxx.h>
#include <yyy.c>

Have you really included yyy.c in another .c file?

...some code
//Calls functions in yyy.c

If xxx.c uses functions from yyy.c, then xxx.c should include yyy.h. Once
it does you will probably find that main.c no longer needs to.

==============

===========yyy.h
...some declarations
==============

===========yyy.c
//Should yyy.h be included here instead?
...some code
==============

I think you need to go back to an introductory text on c and study the
differences between header files and source code files, what #include
means, and what "linking" means. I'm afraid the above is hopelessly
confused. :-(

Dave

--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm






.

Relevant Pages

  • Re: How does free() know how many bytes to free???
    ... A call to freeis used to de allocate memory which has ... or a calloc() call. ... Upon malloc, the size of the buffer is stored somewhere, normally ...
    (comp.os.linux.development.system)
  • Re: xmalloc string functions
    ... Failed malloc() is. ... Why can't you test an allocation failure? ... each can fail on request, each needs to have the request failure dealt ... process Save click because it failed to allocate memory for the event ...
    (comp.lang.c)
  • Re: style question,itoa
    ... able to allocate buffers in some convenient location the callee ... dynamically allocate a block of memory and computing this size to use ... call might require allocating a page for the stack. ... " Checking every single malloc in a bigger application for possible ...
    (comp.unix.programmer)
  • Re: malloc and maximum size
    ... The malloc function takes size_t type argument. ... malloc allocates much much less memory. ... don't assume that you can allocate as much as SIZE_MAX bytes; ... This program compiles fine with gcc 3.4.3 as ...
    (comp.lang.c)
  • Re: xmalloc string functions
    ... Failed malloc() is. ... minor annoyance to a critical failure. ... there is something to recover from. ... Now, if I don't use this half-baked notion of "allocate or die", I can ...
    (comp.lang.c)