So, I am new to pointers to in C.
I am facing a confusion.
If I have,
int a;
Here, I dont allocate memory manually for a. It's done automatically by the compiler.
Now, if in a similar fashion, if I do,
char * a;
Do I need to allocate memory for the pointer?
Secondly, I made this code,
#include <stdio.h>
int main (void)
{
int *s=NULL;
*s=100;
printf("%d\n",*s);
return 0;
}
Why do I get a seg fault in this code? Is it because I havent allocated memory for the pointer? But as asked in the above question, I can simply declare it as well without manually allocating the memory.
PS: I am new to pointers and I am facing confusion in this. Spare me if it is a bad question. Thanks.
Edit: I read the post for malloc on SO.
http://stackoverflow.com/questions/1963780/when-should-i-use-malloc-in-c-and-when-dont-i
It doesnt really solve my doubt.
You don't need to allocate memory for the pointer itself. That's automatic, like the int in your first code snippet.
What you do need to allocate is the memory that the pointer should point to, and you need to initialize the pointer to point to that.
Since you're not allocating any space, the *s= assignment is undefined behavior. s itself (the pointer) is allocated, and initialized to NULL. You can't dereference (*s - look at what the pointer points to) a null pointer.
#include <stdio.h>
#include <stdlib.h>
int main (void)
{
int *s = NULL; // s is created as a null pointer, doesn't point to any memory
s = malloc(sizeof(int)); // allocate one int's worth of memory
*s = 100; // store the int value 100 in that allocated memory
printf("%d\n",*s); // read the memory back
free(s); // release the memory
// (you can't dereference s after this without
// making it point to valid memory first)
return 0;
}
You have to allocate memory for the variable s you are declaring. Malloc is a nice way to do that. With int *s=NULL the pointer does not point to any address. And after that you trying to give a value to that address (*s=100;). If you do not want to allocate memory manualy (with malloc) you simply declare an int variable and then make s pointing to that variable.
With malloc:
#include <stdio.h> int main (void)
{
int *s=NULL;
s=(int *)malloc(sizeof(int));
*s=100;
printf("%d\n",*s);
return 0;
}
Without malloc:
#include <stdio.h>
int main (void)
{
int *s=NULL;
int var;
s=&var;
*s=100;
printf("%d\n",*s);//100
printf("%d\n",var);//also 100
return 0;
}
As pointers are also special type of variables which stores the address of other variables,As the address is also some value(number), Hence memory is also needed to store this address,so compiler automatically allocates memory(exactly 4 bytes on 32-bit machine) to a pointer variable,when you are allocating the memory using malloc() or calloc()your are actually allocating the memory to the data which is to be stored,and simply assigning the starting address of this memory to the pointer.
In your example at the line
int *s=NULL; //this line
Compiler actually allocates memory of 4 bytes (if your machine is 32-bit)
see this small snippet
int main(void)
{
int *s=NULL;
printf("%d\n",sizeof(s)); //Will output 4 if you are using is 32-bit OS or else 2 if you are using using 16 bit OS.
return 0;
}
And NULL is simply just another way of assigning Zero to a pointer.So technically your actually using 4 bytes to store zeros in that pointer. And don't be confused, assigning zero or NULL means that the pointer is not pointing to any data(as it doesn't hold a valid address,Zero is not valid address).
Related
I'm a bit weak when it comes to memory allocation and pointers.
So, I want to understand why do I have to allocate memory to pointers in functions as follow:
char *cstring(char c, int n)
{
int i = 0;
char * res;
res = malloc ((n+1)*sizeof(char));
while (i<n)
{
res[i]=c;
i++;
}
res[i] ='\0';
return res;
}
and why is the following not valid?
char *cstring(char c, int n)
{
int i = 0;
char * res;
while (i<n)
{
res[i]=c;
i++;
}
res[i] ='\0';
return res;
}
I understand that I should allocate memory (generally) to pointers so that they have defined memory.
However, I want to mainly understand how is it related to the concept of stack and heap memories!
Thanks in advance!
Pointers need to point to a valid memory location before they can be dereferenced.
In your first example, res is made to point at a block of allocated memory which can subsequently be written to and read from.
In your second example, res remains uninitialized when you attempt to dereference it. This causes undefined behavior. The most likely outcome in this case is that whatever garbage value it happens to contain will not be a valid memory address, so when you attempt to dereference that invalid address your program will crash.
If you declare a variable like that,
int A = 5;
then that means the variable will be on the stack. When functions are called, their local variables are pushed to the stack. The main function is also an example of that. So you don't have to allocate memory manually, your compiler will do this for you in the background before it calls your main function. And that also means if you examine the stack during the execution of the function you can see the value 5.
With this,
int A = 5;
int *PtrToA = &A;
The pointer will be on the stack again. But this time, the value on the stack just shows the memory address of the actual integer value we want. It points to the address of the memory block that holds the value 5. Since A is held in the stack here, pointer will show a memory address on the stack.
Like the case in your question you can allocate memory dynamically. But you have to initialize it before you read it. Because when you request to allocate the memory, your operating system searches for a valid memory field in your programs heap and reserves that for you. Than it gives you back its adddress and gives you the read write permissions so you can use it. But the values in it won't contain what you want. When compiler allocates on stack, the initial values will be unset again. If you do this,
char *res;
res[1] = 3;
variable res will be on the stack and it will contain some random value. So accessing it is just like that,
(rand())[1] = 3;
You can get an access violation error because you may not have permission to write to that memory location.
An important note; after your function call returns, values of local variables on the stack are no more valid. So be careful with that. Do not dereference them after the function call ends.
In conclusion; if you want to use a pointer, be sure it points to a valid memory location. You can allocate it yourself or make it point another memory address.
The second version of your code declares a pointer, but does not initialize it to point to a valid memory address.
Then, the code dereferences that pointer -- during the loop. So, your code would access uninitialized memory in this case. Remember, array indexing is just syntactic sugar for dereferencing -- so your code accesses memory its not supposed to.
The first version of your code initializes the pointer to actually point to something, and hence when you dereference it during the loop, it works.
Of course, in either case, you return the pointer from the function -- its just that in the first version it points to something valid, whereas in the second version it points anywhere.
The moral here is to always initialize your variables. Not doing so could result in undefined behavior in your code (even if it appears to work sometimes). The general advice here is to always compile your code using at least some compilation flags. For example in gcc/clang, consider -Wall -Werror -Wextra. Such options often pick up on simple cases of not initializing variables.
Also, valgrind is a brilliant tool for memory profiling. It can easily detect uses of uninitialized memory at runtime, and also memory leaks.
Simple: because you do not have any allocated memory for the data you wite. In your example you define pointer, you do not initialize it so it will reference random (or rather not possible to predict) place in the memory, then you try to write to this random memory location.
You have 2 Undefined Behaviours here in 5 lines example. Your pointer is not initialized, and you did not allocate any valid memory this pointer to reference.
EDIT:
VALID
char *cstring(char c, int n)
{
char * res;
res = malloc ((n+1)*sizeof(char));
char *cstring(char c, int n)
{
char * res;
static char buff[somesize];
res = buff;
char buff[somesize];
char *cstring(char c, int n)
{
char * res;
res = buff;
INVALID
char *cstring(char c, int n)
{
char * res;
char buff[somesize];
res = buff;
This is the erroneous code.
#include <stdio.h>
#include<stdlib.h>
int main() {
int* t = (int*) malloc(sizeof(int));
int a = 4;
t = &a;
printf("%d\n",*t);
free(t);
return 0;
}
How can I fix this?
malloc and calloc are used for dynamic memory allocation for arrays. As Blaze said in comments, just removing malloc will solve your problem:
#include <stdio.h>
#include<stdlib.h>
int main() {
int* t;
int a = 4;
t = &a;
printf("%d\n",*t);
return 0;
}
You won't need free as well, because, you did not allocate dynamic memory. Moreover, if you do create dynamic memory for array, I would recommend you to use calloc over malloc, as unlike malloc, calloc initializes memory with zero.
This is what happens in your code:
A pointer t points to an int which is created dynamically
int* t = (int*) malloc(sizeof(int));
Data:
t -> INT
A new variable is created
int a = 4;
Data:
t -> unnamed: integer
a: 4
T is assigned to a
t = &a;
Data:
unnamed: integer
t-> a: 4
This causes a problem, because the dynamically created integer is not referred anymore to. There is also no way to free it now there is no variable pointer to it.
(Trying to) free memory
free(t);
Data:
unnamed: integer
t-> a: 4
Memory cannot be freed because it points to stack space (for in this case local variable), not heap space (for dynamic variables). See comment of Jeremy below.
Solution:
Do not use the malloc and free, and assign t (as pointer) to variable a, after you create a.
Broadly speaking, there are three types of memory available to a C program.
memory for global and static variables
"automatic" memory for function local variables and parameters
dynamic memory which is allocated by the program code itself using functions like malloc().
Automatic memory (I call it that because there used to be a keyword in C automatic you could use to specify it) is allocated automatically from the program stack or the CPU's register file when a function is entered and automatically deallocated when the function is left.
Dynamic memory is allocated from the "heap" which is basically just a heap of memory not in any particular order.
In your code you have automatic and dynamic allocations:
int* t = (int*) malloc(sizeof(int));
This code allocates memory for a pointer on the stack (t) and enough memory for an int from the heap. A pointer to that memory is saved in t
int a = 4;
This code allocates memory for an int on the stack (a) and saves the int 4 in it.
t = &a;
This code gets a pointer to a (which is allocated from the stack) and stores it in t.
Note that the previous content of t the pointer to the dynamically allocated block of memory from the heap has now been lost. There is now no way for your program to deallocate the heap memory. This is called a memory leak and, in larger programs, bugs of this nature cause the memory usage to keep going up until the system grinds to a halt or the program fails because it can't be allocated any more heap memory.
printf("%d\n",*t);
This just prints out what is pointed to by t i.e a which is 4.
free(t);
free() is used by the C library to return memory that was allocated from the heap back to the heap. Unfortunately, t no longer points to memory from the heap, it points to memory on the stack. It's likely that this line corrupts the heap. Were you not about to exit the program, it would be a disaster.
So I decided to write my own Big Integer library for a microcontoller in C (the PIC32 if that matters), but I'm having a weird problem that I don't understand. When the code is run, the big_int_t structs a and b are at different memory locations, but a->bytes and b->bytes appear to be at the same location (confirmed by printing their pointers). Setting a value in b->bytes also changes the value in a->bytes. In the main function below, printing the first element from either struct's bytes array shows 41. Am I doing something wrong?
#include <stdint.h>
#include <stdio.h>
typedef struct {
uint8_t size;
uint8_t *bytes;
} big_int_t;
void big_init(big_int_t *big, uint8_t size) {
big->size = size;
uint8_t bytes[size];
big->bytes = bytes;
uint8_t i;
for(i=0;i<big->size;i++) big->bytes[i] = 0;
}
int main() {
big_int_t a,b;
big_init(&a,1);
big_init(&b,1);
a.bytes[0] = 16;
b.bytes[0] = 41;
printf("%d\n",a.bytes[0]);
printf("%d\n",b.bytes[0]);
}
In big_init the variable bytes is a local Variable, one that will go out of scope and disappear once the function returns. The pointer stored in big->bytes will become a stray pointer when the function returns, and dereferencing the pointer will lead to undefined behavior.
You can't use a local array for this, instead you need to allocate the array dynamically with malloc:
big->bytes = malloc(sizeof(*big->bytes) * big->size);
But don't forget to free the memory once you're done with it.
You are allocating your byte buffer on the stack:
uint8_t bytes[size];
When big_init exits the buffer is no longer valid. It will get randomly overwritten.
You probably want to dynamically allocate it using malloc(), but then you have to be careful to free it up again.
The reason for this behaviour is that you are assigning bytes with a pointer on the stack. When calling big_init for the first time, the local variable bytes will be placed on the stack and it's address will be used for bytes in the struct. Afterwards, you are calling the function big_init again. Now, the same stack as before is build up, and the local variable bytes is placed on the same location as before. Therefore, the two assignments lead to the same pointer.
The following application works with both the commented out malloced int and when just using an int pointer to point to the local int 'a.' My question is if this is safe to do without malloc because I would think that int 'a' goes out of scope when function 'doit' returns, leaving int *p pointing at nothing. Is the program not seg faulting due to its simplicity or is this perfectly ok?
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
typedef struct ht {
void *data;
} ht_t;
ht_t * the_t;
void doit(int v)
{
int a = v;
//int *p = (int *) malloc (sizeof(int));
//*p = a;
int *p = &a;
the_t->data = (void *)p;
}
int main (int argc, char *argv[])
{
the_t = (ht_t *) malloc (sizeof(ht_t));
doit(8);
printf("%d\n", *(int*)the_t->data);
doit(4);
printf("%d\n", *(int*)the_t->data);
}
Yes, dereferencing a pointer to a local stack variable after the function is no longer in scope is undefined behavior. You just happen to be unlucky enough that the memory hasn't been overwritten, released back to the OS or turned into a function pointer to a demons-in-nose factory before you try to access it again.
Not every UB (undefined behaviour) results in a segfault.
Normally, the stack's memory won't be released back to the OS (but it might!) so that accessing that memory works. But at the next (bigger) function call, the memory where the pointer points to might be overwritten, so your data you felt like bing safe there is lost.
malloc() inside a function call will work because it stores on heap.
The pointer remains until you free the memory.
And yes, not every undefined behaviour will result in segmentation fault.
It does not matter that p does not point at anything on return from doit.
Because, you know, p isn't there any more either.
It does matter that you are reading the pointer to a no-longer-existing object in main though. That's UB, but harmless on most modern platforms.
Even worse though, you are reading the non-existent object it once pointed to, which is straight Undefined Behavior.
Still, nobody is obliged to catch you:
Can a local variable's memory be accessed outside its scope?
As an aside, Don't cast the result of malloc (and friends).
Also, be aware that not free-ing memory is not harmless on all platforms: Can I avoid releasing allocated memory in C with modern OSes?
Yes, the malloc is needed, otherwise the pointer would point on the 4-byte space of the stack, which would be used by other data, if you called other functions or created now local variables.
You can see that if you call that function afterwards with a value of 10:
void use_memory(int i)
{
int f[128]={};
if(i>0)
{
use_memory(i-1);
}
}
I am learning how to use pointers, so i wrote the below program to assign integer values in the interval [1,100] to some random locations in the memory.
When i read those memory locations, printf displays all the values and then gives me a segmentation fault. This seems an odd behavior, because i was hoping to see either all the values OR a seg fault, but not both at the same time.
Can someone please explain why i got to see both?
Thanks. Here is the code
#include <stdio.h>
#include <stdlib.h>
int main()
{
char first = 'f';
char *ptr_first = &first;
int i=1;
for(i=1;i<101;i++)
*(ptr_first+i) = i;
for(i=1;i<101;i++)
printf("%d\n", *(ptr_first+i));
return EXIT_SUCCESS;
}
Not odd at all. You are using your variable first, which is on the stack. What you essentially do is happily overwriting the stack (otherwise known from buffer overflows on the stack) and thus probably destroying any return address and so on.
Since main is called by the libc, the return to libc would cause the crash.
You're accessing memory past beyond that assigned to first. It is just one character, and, through the ptr_first pointer, you're accessing 100 positions past this character to unreserved memory. This may lead to segfaults.
You have to ensure the original variable has enough memory reserved for the pointer accesses. For example:
char first[100];
This will convert first in an array of 100 chars (basically a memory space of 100 bytes that you can access via pointer).
Note also that you're inserting int into the char pointer. This will work, but the value of the int will be truncated. You should be using char as the type of i.
since ptr_first pointer is pointing to a char variable first. Now when you are incrementing ptr_first, so incremented memory address location can be out of process memory address space, thats why kernel is sending segmentation fault to this process.