Hello members,
I have following code built successfully with MDK-ARM v4.7.
void FS_update_version_info (void) { char *file_src, *file_dest;
strcpy(&file_src[0], folder_path_config); strcat(file_src, file_path_config); strcpy(&file_dest[0], folder_path_config); strcat(file_dest, file_path_config_temp); }
When I debug the code, I found that variable "file_dest" is not getting memory allocated, hence it is not getting updated with the assigned value. I tried increasing stack/heap values from startup file. Also tried increasing IRAM1 option from Target->Options dialog but no use. Any idea what is the reason for this? I am using RL-TCP, RL-USB and RL-FlashFS libraries in my code.
Thanks in advance for any help.
Mike.
Of course, this function produces no side effects, so the compiler might as well optimize it away altogether. By the way, some language extensions do allow to specify that the function works only on its arguments and doesn't do anything besides that, so that the compiler would be able to see 'no side effects' cases. This could be happening here.
Of course, this function produces no side effects, so the compiler might as well optimize it away altogether.
The result is correct, but I don't think the reasoning is. The OP's function has the nastiest side effect possible: it causes undefined behaviour by writing (and reading) through un-initialized pointers.
The compiler is still at liberty to optimize away that function, though, because "do nothing at all" is a perfectly valid implementation of undefined behaviour.
The result is correct, but I don't think the reasoning is.
It's not even certain that the result is correct.
There's nothing to say that the functions strcpy and strcat are the standard C library functions. They don't have to be. They could be implemented elsewhere in the project and they might have side effects. If they have side effects, then the compiler should not then simply remove calls to them; even if the calling code is floored like the OPs.
Why stop here? For all we know, every word in the code could be a macro, like in some obfuscated C code contest :-)