If you got an EXEC_BAD_ACCESS on that atoi, i suspect we did fix the one problem and hit a new one, because the only way you could get that is if STRTOK returned null, meaning you probably tried to tokenize something that doesn't make sense to it based on your other strtok calls (in particular, something with less than 2 '/' characters in it)
The main problem is that it is hard to edit the function to run on data I make because I do not know exactly what it is supposed to do, and a lot of it looks "like magic" to me -- indices clearly have significance, but without knowing what, I have no idea what the goal is.
What might help: I will describe in words what it looks like the function is doing. If the words don't match what you want, then we found a bug to squash. Sometimes it helps to see what someone else thinks your code does, since it is easy to go code-blind and not notice things in the code.
So, here we go:
convert_dates must be passed in an array of at least 4362 pesto objects, and days is length of the signal array. Any less than 4362 objects and it will crash at best, and corrupt other data on the stack at worst. Sizes larger than 4362 look buggy to me, but it might be intended.
The function is going to do extensive modification to the passed in object, but what it does is strongly dependent on the length of the array.
The meat of the loop (which is run exactly 1062 times no matter the length of the signal array) converts dates.
The input format M/D/Y, where M and D might or might not be 0-padded, and Y might be any number of digits (but probably 2 or 4).
The output format is YYYYMMDD, where M and D are 0-padded to be 2 digits each, and Y usually 4 digits but not always. Input dates between 1 and 89 inclusive are converted to 20YY, and any dates larger than 90 have the two digits "19" prepended. So, if the initial year happened to be "2000", the output year will be "192000". This leads me to guess that the input data always uses 2-digit years, but without seeing it, I have to guess. (Negative input years, like say -1, would be converted to 19-1. I assume that this does not happen in the data the program is meant to run on, but since you do check for year>0, I am less sure on that assumption. But I doubt you want 19-1). A year of 0 (not 00) converts to 190, so you can have a 3-digit year.
So, that is the conversion. Now, where that converted date is supposed to go is what strongly depends on input size.
If the input length is 4362, then element 0 of the array will have its date set to to the converted date from element 3300 in the array. Also, element 0 of the array will have its signal set to the signal of element 3300. The loop then progresses forward, setting the date and signal of element 1 to that of 3301, and so on. This seems more or less ok (though moving some data back 3300 elements seems a little odd, but not immediately standing out as buggy)
If the input length is 4363, as above, but this time we set the date of element 1 and the signal of element 0 from the element at 3301 (so, we split them up rather than assigning them to the same object). Then the date of 2 and the signal of 1 are copied from 3302. And so on.
If the input length is 4634, as above, but the date from 3302 goes to 2, and the signal from 3302 goes to 0. Then the date on 3 and the signal on 0 are copied from 3303, and so on.
And so on
So, for every element in the input array over 4362, the date and signal are copied that many elements apart at the start of the array (without knowing what exactly you WANT, this feels very buggy to me)
If the input length is less than 4362, bad things happen. Lets look at length 4361. In that case, i will start at 4361-1062=3299. And then at the bottom of the loop, when this line is called
strcpy(signal[i - 3300].date,new_date);
we'll try to set signal[-1]'s date. As I said above: best case scenario, that crashes. Worst case, it doesn't crash, silently corrupts your memory, and almost anything could happen. (this also feels buggy to me, but again, I don't know your goal, so maybe it isn't)
Because of this length dependence, i can't change the length without also changing the behavior, and without knowing what behavior is intended, doing that might cause the bug you see not to manifest.
Do those words more or less match the intent of the function? I specifically called out some special cases that might not apply. The date conversion, for example, is perfectly fine if the input data ALWAYS uses exactly 2-digit non-negative years. It only misbehaves on 1- or 3+-digit years, or negative years. But I don't know your data, so I cannot verify that, so I called out the places it fails. And maybe the input is always 4362 elements long, in which case the things that feel buggy aren't functionally a problem (but are still a problem because if the function is used on future data that is different it will explode)
If not, where are they different? I might have misread the code, or the code might be doing things wrong.
