Variable not getting memory allocated

You have two auto variables located on the stack.

That means that there have been space allocated for them on the stack.

But since the two variables are of the data type pointer-to-char, it is only the pointers that have memory allocated.

You (!) then need to allocate memory blocks and assign these two pointers to point at your allocated memory blocks, before you can start to use the pointers as destination for your string-copy.

This is standard C.

Memory doesn't get randomly allocated from the heap, unless the developer explicitly calls any function that performs heap allocation.

strcpy() and strcat() only copies data - they both assume that the destination pointer already points to valid memory - your two pointers have never been assigned any valid address to valid buffer space for strcpy() and strcat() to place any data.

You have two auto variables located on the stack.

That means that there have been space allocated for them on the stack.

But since the two variables are of the data type pointer-to-char, it is only the pointers that have memory allocated.

You (!) then need to allocate memory blocks and assign these two pointers to point at your allocated memory blocks, before you can start to use the pointers as destination for your string-copy.

This is standard C.

Memory doesn't get randomly allocated from the heap, unless the developer explicitly calls any function that performs heap allocation.

strcpy() and strcat() only copies data - they both assume that the destination pointer already points to valid memory - your two pointers have never been assigned any valid address to valid buffer space for strcpy() and strcat() to place any data.

Thanks for your reply. You mean assigning a fixed address to these variables? These are local to functions, shouldn't be taken care by stack? Any examples?

Thanks for any help.

Mike.

A pointer has to point to something - doesn't it?

In your code, as posted, where do the pointers point to...?

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 :-)