Is it safe to return a struct in C or C++?

It's perfectly safe, and it's not wrong to do so. Also: it does not vary by compiler.

Usually, when (like your example) your struct is not too big I would argue that this approach is even better than returning a malloc'ed structure (malloc is an expensive operation).

It's perfectly safe.

You're returning by value. What would lead to undefined behavior is if you were returning by reference.

//safemystruct func(int c, int d){    mystruct retval;    retval.a = c;    retval.b = d;    return retval;}//undefined behaviormystruct& func(int c, int d){    mystruct retval;    retval.a = c;    retval.b = d;    return retval;}

The behavior of your snippet is perfectly valid and defined. It doesn't vary by compiler. It's ok!

Personally I always either return a pointer to a malloc'ed struct

You shouldn't. You should avoid dynamically allocated memory when possible.

or just do a pass by reference to the function and modify the values there.

This option is perfectly valid. It's a matter of choice. In general, you do this if you want to return something else from the function, while modifying the original struct.

Because my understanding is that once the scope of the function is over, whatever stack was used to allocate the structure can be overwritten

This is wrong. I meant, it's sort of correct, but you return a copy of the structure you create inside the function. Theoretically. In practice, RVO can and probably will occur. Read up on return value optimization. This means that although retval appears to go out of scope when the function ends, it might actually be built in the calling context, to prevent the extra copy. This is an optimization the compiler is free to implement.

The lifetime of the mystruct object in your function does indeed end when you leave the function. However, you are passing the object by value in the return statement. This means that the object is copied out of the function into the calling function. The original object is gone, but the copy lives on.