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.
void FS_update_version_info(void) { char file_src[64], file_dest[64]; // Allocate some memory (enough) for this stuff strcpy(file_src, folder_path_config); strcat(file_src, file_path_config); strcpy(file_dest, folder_path_config); strcat(file_dest, file_path_config_temp); // when exits here file_src and file_dest lose scope and are destroyed }
Some pretty basic C concepts at work here.
Mr Pier,
I'm sure you're aware that you've broken one of the deadly sins by posting a direct solution to the OPs question. You'll have the frequent posters jumping up and down and generally seething.
Good on ya :)
"Direct action differs from conventional offensive actions in the level of physical and political risk, operational techniques, and the degree of discriminate and precise use of force to achieve specific objectives"
But I don't see you giving out any fish.
Nor, even, any fishing lessons.
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 :-)