Char** array first element being modified magically - c

Question

I am sorry for the vague title, but I am having a very hard time figuring out how to describe this issue. I am trying to add data to an array and somehow it is all getting written to index 0 despite my explicitly indicating otherwise. I have created a minimal sample.
Expected Behavior
With command line arguments as -u rwx -g rw -o r:
bins[0] == "111"
bins[1] == "110"
bins[2] == "100"
Actual Behavior
Indices 0, 1 and 2 all end up as "100". If you put a printf() to check their value inside the various case statements, you will find that, for instance, when case 'g': runs, bins[1] == "110" AND bins[0] == "110". When case 'o': runs, all three indices will will hold the value "100".
Minimal functional sample
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void processPerms(char *targets, char **perms, char **bins, const size_t arrSize) {
for(int i = 0; i < arrSize; i++) {
//This string will be modified
//so that the right bits will
//be set.
char binDig[] = "000";
//We decide which, if any, bit
//to set based upon the current
//letter being considered.
for(int k = 0; k < strlen(perms[i]); k++) {
switch(perms[i][k]) {
case 'r':
binDig[0] = '1';
break;
case 'w':
binDig[1] = '1';
break;
case 'x':
binDig[2] = '1';
break;
}
}
//Here, we check the target
//whose index corresponds to
//the index of the permissions
//string we just accessed.
//They will always be in
//an order where the related
//target and perm str are in
//the same array position.
switch(targets[i]) {
case 'u':
bins[0] = binDig;
//bins[0] == "111"
break;
case 'g':
bins[1] = binDig;
//bins[0] == "110"
break;
case 'o':
bins[2] = binDig;
//bins[0] == "100" && bins[1] == "100"
break;
}
}
}
int main(int argc, char *argv[]) {
const size_t arrSize = (argc-1)/2;
char *targets = (char*)calloc(arrSize, sizeof(char));
char **perms = (char**)calloc(arrSize, sizeof(char*));
//Copying just the letters
//of the args into these
//arrays.
for(int i = 0; i < arrSize; i++) {
targets[i] = argv[i+(i+1)][1];
}
for(int i = 0; i < arrSize; i++) {
perms[i] = argv[i*2+2];
}
//This array should hold three
//strings which shall be binary
//representations of the
//permissions
char **bins = (char**)calloc(3, sizeof(char*));
processPerms(targets, perms, bins, arrSize);
return 0;
}

Answer 1

bins[2] = binDig;
This will make you point to a variable which has automatic storage duration. This is a gateway to undefined behavior when you are returning it from the function. The life time of the variable is over as in this case and accessing it is UB.(Dereferencing a pointer to variable beyond its lifetime is Undefine d behavior).
A easy solution would be to use (This is part of POSIX standard but it is common enough) (In case you don't have this, you can allocate memory and copy to it the content of the array binDig).
bins[2] = strdup(binDig);
(Make the same changes for bins[0] and bins[1]).
Making this change as mentioned gives the expected behavior of being bins[0] equal to "111" and so on. The only thing is that, you need to free the dynamically allocated memory (including as that of returned by strdup
when you are done working with it). Similarly, don't cast the return value of malloc,calloc etc(because void* to char* is an implicit conversion). And check the return value of malloc/calloc.

Answer 2

The lifetime of you binDig array is limited by one iteration of the outer for cycle. This binDig array gets destroyed at the end of each iteration and created anew at the beginning of the next iteration.
This means that everything you do during each iteration of the outer cycle is lost when that iteration ends. The value of bins[] that you assigned during that iteration begins to point to some indeterminate location in memory where nothing exists anymore. Any attempts to access data through the corresponding bins[] entries lead to undefined behavior.
In real life each iteration of the cycle will typically recreate binDig at exactly the same location in memory, which creates an illusion of all of your bins[] pointers remaining valid but pointing to the same value. But this is a mere illusion. The behavior is already undefined at that point.
When the outer cycle ends the binDig array disappears forever and all your bins[] pointers become hopelessly invalid for good. But that's just the last straw. Your program died well before that moment.