Printable View
I'm new to c programming, but my main concern is the memory management?
How? When? Why? should I allocate memory?
Do I need to allocate memory for i?Code:int i;
when I use pointers to structs I do as above, but is it only for pointers I need to allocate memory?Code:struct some_type *p;
p = (some_typ *)malloc(sizeof(p));
> Do I need to allocate memory for i?
No.
> p = (some_typ *)malloc(sizeof(p));
Don't cast malloc. Also i think you'll be wanting sizeof(struct some_type) (or sizeof(*p)).
> is it only for pointers I need to allocate memory?
Pretty much. You don't need to allocate memory for char string[100], for example, but you do for char *string. Well, that's if you don't make it point to a character array instead:
Code:char string[100], *str;
str = string; /* str points to string[0] */
i'll try to explain it another way.
if at the beginning of the program you know exactly how many data types and from which type - you are going to use in your program than you dont have to allocate memory at all.
usually programmers are using this utility when they run a program and during the run they might need to create new data types, for example lets say my program contains an empty linked list and start to run an infinite loop, whenever the user enter an int the program adds another unit to the linked list with that int (every unit in the linked list will be a structure with an int to contain the user input and a pointer to the next unit) you see, i can't tell in advance how many unit (i.e. structures) im going to use in my program so in the infinite loop i'll have to allocate memory to create a new structure whenever the user enters an input int, i need to make sure there will be somewhere malloc() and of course at the end i'll have to free all the memory spaces i used.
as for your example the structure could be defined in a program:
struct some_type p;
and than the memory is allocated as well, you dont have to use malloc,
again use the memory allocation tools only if during the run of the program u need to dynamically allocate memory.
i hope i've been helpfull,
any questions??
i's memory is allocated automatically on the stack and gets freed automatically when you leave whatever routine you're in - be it another function or main.Quote:
Do I need to allocate memory for i?
Anything allocated memory with malloc() is declared on the heap which does not automatically get freed - the data persists until it has been free()d.
why "don't cast malloc" ? because it is automatic or because it is wrong?Quote:
Originally Posted by Tommo
if you understand the concept of pointers well you wont be asking this question..Quote:
Originally Posted by micke_b
there are few things that generally are not covered in beginner books.. though they are related to pointers..
they are good in their own way
I found This Tutorial very useful, interesting and informative..
there is a pdf version of that too..
I am sure it will help you a lot if you go through it.. ( atleast go through chap 1,2 & 9)
faq helpsQuote:
Originally Posted by sloppy
I know what a pointer is, and from the pdf you linked I read that the casting of malloc is not wrong, it is just not needed and obsolete. (as I suspected above)Quote:
Originally Posted by gibsosmat
Anyway thanks.
> why "don't cast malloc" ? because it is automatic or because it is wrong?
See the FAQ
Yes, it's automatic.
It's not wrong per-se, when the rest of the code is correct.
However, there are some mistakes you can make which a cast will cover up, which can be very bad news down the line.
I should have been more clean in my last post..Quote:
Originally Posted by sloppy
but the links I gave are not for you.. its for the person who started this thread..
and the link I posted below your quote is for you.. faq explains it.. suppression of error variables
in man pages malloc is not a stdio.h function..
but it works as I think most of the compilers let it go..
even if you dont include stdio.h the code compiles well.. but with warnings..
so its always better not take warnings from compiler
My fault... I read in hurry :-PQuote:
Originally Posted by gibsosmat
s/stdio/stdlib/ ?Quote:
Originally Posted by gibsosmat
Also, consider that in some processor architectures & ABI combinations, a pointer may not always be returned in the same register as an integer value (e.g. integer values in D0, pointers in A0 in 68000 processors), in which case a non-prototyped malloc() would make the code break. Casting the call will potentially hide this and make the compiler not tell you that it will break.
--
Mats
its in stdlib.hQuote:
Originally Posted by matsp
I dont think so. as its the compiler that generates the malloc subroutine..Quote:
Originally Posted by matsp
so it should take care of those architecture problems
and also its the system allocating the memory chunk and malloc routine is handling the usage of that to see how much more should it ask the next time..
If it is non prototyped and the compiler takes care of that by considering including the required headers.. I dont think that would cause problem if compiled on the specific architecture..
Thank guy, that answered all my questions. :)
Thanks for the links, will be reading them tonight. ;)
Not so. If you don't have a prototype [at least a basic "return type" declaration - arguments isn't important for the discussion here] on a system that uses different registers for different types [this applies to for exampl floating point returns in FPU registers too], then the compiler will not KNOW that the return value from malloc() is a pointer, and thus assume that it's an integer type operation and use the wrong register. How is the compiler going to know what the return type is if it's not been told - the compiler doesn't KNOW intrinsically that malloc return a pointer. For that matter, if you don't actualy need the malloc function in the C library, you could very well write another function called malloc() that does somethign completely different - the compiler should be able to compile this too.Quote:
Originally Posted by gibsosmat
--
Mats
Just another question. From the faq:
"...There is nothing wrong with this except in the event that stdlib.h, the header which declares malloc, is not included. If the return of malloc is cast then the error which would be flagged is hidden..."
why doesn't the compiler give an error if I do not include stdlib.h? Shouldn't it complain about not knowing funcion "malloc"?
I think there is a confusion with the term I used 'compiler'.Quote:
Originally Posted by matsp
I meant to say that the total process of compilation & linking at once. (Ex: cc -o test test.c)
Well, then lets talk in real terms of 2 stage building compiling & linking..
Still if I make my own malloc and call it in my program without prototyping
and in the end if I link it with the libc malloc.. that should work and malloc code will be generated. but the problem is that our call stack is not the way we wanted and the system dosent know that. It continues to execute the instructions until it violates some system's rules, so the error is undefined as it depends on the stack of that program.
i.e: if I use my custom void* malloc(int,int)
and I link it with std malloc
the compiler generates the code for malloc in the ASM level handling what to copy where.. etc..
but the problem is that malloc only used only one argument that we provided.
the next stack entry is still there and that will mess up the remaining of the stack..
so the next stack frame interprets it wrong again and do its own job untill it does something illegal as per the systems rules..
correct me if I am wrong..
I tryed quickly and it seems that if I do not include stdlib.h I get:
prova.c: In function 'main':
prova.c:7: warning: incompatible implicit declaration of built-in function 'malloc'
both with and without casting
ya.. it does but not an error it will gives a warning..Quote:
Originally Posted by sloppy
as malloc is built-in function.. and its the same for all the built-in functions.
but if you use a different function that is not built in it will throw error and not warning
I think this is for the ease of programming that built-in functions are trivial to declare until something else is explicitly stated to be the overriding function of these built-ins.
I dont know what the technical reason is..
@sloppy
Which compiler, and what command line did you use?
> but the problem is that malloc only used only one argument that we provided.
> the next stack entry is still there and that will mess up the remaining of the stack..
In C, it is the caller's responsibility to clean up the space used by parameters. The caller will know two values were pushed, and therefore knows to pop off two values.
> Still if I make my own malloc and call it in my program without prototyping
> and in the end if I link it with the libc malloc.. that should work and malloc code will be generated.
Only if you ignore what matsp wrote in post 11.
The real malloc returns a pointer, but in the absence of any prototype your code will think malloc will return an int. Even if you assume that the same register is used, you're also assuming that int and pointer have the same size.
Most compilers probably only give a warning about using a function without prototype [and there's of course no guarantee that there's no other header file that drags in the appropriate header - e.g. stdio.h may drag in stdlib.h by "fluke" - and then it stops working when you move to a different system where stdio.h doesn't drag in stdlib.h].Quote:
Originally Posted by sloppy
If you use gcc , add -Wall. In Visual Studio, you should use -W4 or -W3.
--
Mats
@Salem
I use gcc4 under linux (command line bash... does it depend on command line?)
@gibsosmat
it seems to me that the error doesn't come for built-in funcions even if I do not cast. but maybe it depends on my compiler...
PS:
Using "gcc -S" vs "g++ -S" to get assembly output of a custom malloc(int,int) functions it seems that gcc calls malloc, whereas g++ renames the custom malloc and calls the custom malloc.
I use gcc. What I am saying is that I get the same warning both casting or not casting (adding -Wall doesn't give me error... just warning). Son I don't think (***at least on gcc4***) that it mayQuote:
Originally Posted by matsp
"...resulting in a difficult to find bug..." (from faq)
The compiler doesn't need to "know" about a function in order to let you call it. If there is no function prototype, the compiler ASSUMES that the prototype is:Quote:
Originally Posted by sloppy
In other words, it assumes the function takes any and all parameters (meaning the compiler will not do any argument type checking for you), and it assumes that it returns an int.Code:int func()
The compiler will usually print a warning when you call a function that hasn't been prototyped. But it won't stop you from doing it.
Because malloc() actually returns a void *, not an int, this means that if you fail to include stdlib.h, you will have to explicitly cast the result. If you explicitly cast anyway, this can mask the fact that you forgot to include stdlib.h.
It has nothing to do with malloc() being a "built-in" or anything like that. It's like this for all functions.
if you add -Wall, gcc/g++ will give you warnings when you "do things wrong". This is what Salem means by "command line" - what you give gcc as a command-line, not which shell you may be using.Quote:
Originally Posted by sloppy
As to "if you define your own malloc with another interface", the difference you see with malloc in C and C++ is that C++ takes into account the arguments if you don't usearound the function. So the "renaming" you see is the fact that it's being "decorated" (aka "mangled") to indicate the argument types of the function.Code:extern "C"
--
Mats
am using the same.. so things dont change much..Quote:
Originally Posted by sloppy
but its like a habit that few ppl learn how not to before learning how to :)
I am one of them..
btw I dont like that .s file.. and I didnt do 2 of my assignments which wanted me to comment whats going on in sparc & PC architecture :(
I found it to be the worst thing to be done and calling it a programming assignment. :D
still I will learn it latter :D
Doesn't gcc4 default to C99 behaviour, which makes implicit declarations of functions illegal?
I do not know the default. But If I add to the command line "-std=c99" I get one more warning:Quote:
Originally Posted by Salem
prova.c:10: warning: implicit declaration of function 'malloc'
(always both with and without casting)
Not with GCC 4.1.2:Quote:
Originally Posted by Salem
Running "gcc foo.c" gives no warnings. I have to use -Wall to getCode:main(void) {
return 0;
}
foo.c:1: warning: return type defaults to ‘int’
C99 is not the default behavior. From "man gcc":
std=gnu89
Default, ISO C90 plus GNU extensions (including some C99 fea-
tures).
It's not likely that C99 will be the default until the support for it is essentially complete.
http://gcc.gnu.org/c99status.html