Re: Simple question about headers and malloc!




"Robby" <Robby@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:81F60840-6CBB-4815-9D2E-EE2DB021C218@xxxxxxxxxxxxxxxx

I find myself in a bind where I *must* specifically include the yyy header
file (see code sample below) in main even though all its declarations are
specifically used for yyy.c. Therefore I am making all of its declarations
global to the whole program! and I don't like it !

The whole point of declaring function prototypes in yyy.h of functions in yyy.c is that you can include yyy.h also in the files which contain calls to the functions in yyy.c, and the calling functions know what they're calling.

It isn't global to the whole program unless all .c files used to build the program have calls to things in yyy.h. In which case the function prototypes *must* be available to all of them.

The reason for this is because when I am in yyy.c file I am allocating
memory (using malloc) and then exit back to main. I later call again
functions in yyy.c and allocate another block of memory (using malloc) and
further continue some logic in yyy.c. As I I read data from first memory
allocation, I get data strored from the second allocation... even though I
didn't free the first malloc allocation! I don't free it because I need to
use both data in the memory allocated by both mallocs. But each allocation is
done at different times!!!!!

Therefore, I think that when you exit a function where you used malloc, its
pointer is lost right? ...

Only if you lose it, and you mustn't.

If you allocate memory, it is your resonsibility to keep track of a pointer to that memory, and free the memory when you have finished with it.

malloc will not normally allocate memory overlapping with already-allocated memory. You must be doing something horribly wrong.

At a later instance if I go back in yyy.c and do another malloc , since the
pointer to the previous memory allocation is lost, I think that the previous
memory block is up for grabs by the next malloc command

No. You have allocated memory and forgotten where it is. You haven't freed it. You have what is known as a memory leak.

and this is where
data gets mixed up. So this is why I am including the yyy.h file in main so
all pointers returned from mallocs always stay valid and all allocations are
reserved at all times.

That shouldn't help. But have you got somethiing horrible in yyy.h???

There are other files between xxx.c and yyy.c and would be quite lenghty to
explain it all,

Then there is a lot of scope for something unexplained to go wrong.

but I hope its clear enough to get a general idea.

A "general" idea is usually insufficient for debugging.

Making all
pointer declarations that will be used with malloc commands in a global
header file

Ah, now you're talking. You have just declared a pointer in the header file - eg

int * pMyInteger;

?????

And you're using it in two .c files? This is not a good idea. Have you stepped through the program to see where it is pointing in the two different ..c files? One .c file will have a pointer called pMyInteger and so will the other one. They will not be the same.

There are ways to do this: for example put int *pMyInteger; in one of the ..c files and declare

extern int *pMyInteger;

in the other. But this usse of global variables is pretty horrible style in almost all cases.

...is the only way I see that preserves memory allocations when
mallocs are done at different times since the pointers returned by malloc are
never lost.

It won't.

I don't really think I would like to return pointers returned by
malloc back to main in order to preserve them.

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 filre with the same name) until you free the memory. Passing it back to the function which "owns it" is the way this is done.

void MyFuncion()
{
int *pMyInt = someOtherFunctionWhichAllocatesMemory( ... );
//......
someOtherFunctionWhichFreesMemory( pMyInt );
pMyInt=NULL; // For safety as it is no longer valid.
//....
}

The called functions can be malloc and free, or they can be your own functions which call malloc and free somewhere down the line.

...
This obviously compiles

Few things are obvious in this life, and this is not one of them. :-(

but
not sure if this is a good C programming practice. Any feedback appreciated.

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

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

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
==============

===========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

  • Simple question about headers and malloc!
    ... Therefore I am making all of its declarations ... memory (using malloc) and then exit back to main. ... allocation, I get data strored from the second allocation... ...
    (microsoft.public.vc.language)
  • Re: Simple question about headers and malloc!
    ... Therefore I am making all of its declarations ... memory (using malloc) and then exit back to main. ... allocation, I get data strored from the second allocation... ...
    (microsoft.public.vc.language)
  • Re: svn - but smaller?
    ... rather than just having a gigantic portion of memory allocated ... limits of the underlying application. ... larger than 2048 might warrant use of malloc. ... of static vs. dynamic allocation, ...
    (freebsd-stable)
  • Re: xmalloc string functions
    ... than a NULL return from malloc(). ... Memory is quite a different kind of resource. ... I try to write my code so any allocation failure is handled ... its not likely that one will be more susceptible to failure than the other. ...
    (comp.lang.c)
  • Re: A solution for the allocation failures problem
    ... reduce the effort involved in managing memory. ... Releasing such buffer may not effect the ability of malloc() to return ... says it releases the memory for subsequent allocation, ... Dealing with the failure "at point of failure" isn't inherently evil. ...
    (comp.lang.c)