#include <string.h>
void testok(void) reentrant { char buff[20];
buff[0]=1;
strcpy(buff,"hello");
//ok: buff = "hello"
}
void testfail(void) reentrant { char buff[20];
buff[0]=1; buff[2]=2;
//fail: buff = "ello"
void main(void) { testok(); testfail(); }
There's nothing that code actually needs to do, thus nothing it could possibly do incorrectly.
And the use of "reentrant" doesn't change that in any way.
Encounter such a structure will be a problem
someone said something about side effects some days ago like if strcpy is not the normal library function. I think (s)he is right.
Don't worry about strcpy() right now.
Instead consider how you intended your two functions to actually perform some action that means something to the main loop or to the state of peripherials or GPIO based on the result you got.
Not strcpy () error asm view call strcpy, the buff (mov Rx) address error
like if strcpy is not the normal library function.
That doesn't apply here, thanks to this code example containing the key line
It cannot be in error, because the whole code is you posted is functionally equivalent to
void main(void) { // do nothing // OH, and by the way, what do you think happens after this line? }
It doesn't matter one bit how the compiler invoked strcpy(), nor even whether it called strcpy() at all, because immediately after that line in the source the lifetime of the affected variable ends anyway. So whatever happened to this variable doesn't matter.
that doesn't mean that the code of strcpy is really the one in the library. it only says the proto type.
so pc programs that do return don't do anything?
That would be true for non-standard library functions. But C Standard Library functions are different: once you've included their respective Standard Header, any attempt at overwriting their implementation would cause undefined behaviour, so all bets would be off anyway.
Whether or not they do return has nothing to do with it. But yes, it's possible to write a seemingly complex PC program that still ends up being functionally equivalent to
int main(void) { return 0; }
The only thing your two functions might do is consume time. And consumed time isn't really something the compiler needs to care about. Which is also why software-only busy loops are normally so bad.
I do not think you are right. the header file only has the prototype. not the implementation. lots of compiler have the source to libraries and you can change. they can be changed. you probably thinking of intrinsic.
they can be changed.
And any change that makes the function called strcpy() behave differently from the C Standard's requirement causes undefined behaviour.
you probably thinking of intrinsic.
No.
A failure of this would be far more convincing
#include <stdio.h> #include <string.h> void testok(void) reentrant { char buff[20]; buff[0]=1; strcpy(buff,"hello"); puts(buff); } void testfail(void) reentrant { char buff[20]; buff[0]=1; buff[2]=2; strcpy(buff,"hello"); puts(buff); } void main(void) { testok(); testfail(); }