There is no sense, in C++, in which a naked pointer implies or suggests ownership. It is the opposite: the continued validity of a pointer value depends on ownership maintained elsewhere. Nowadays libraries keep track of ownership. Most commonly the library delegates that responsibility to Standard std::unique_ptr, for familiarity. Not doing that indicates something different in play.
(It is, in fact, UB even in C to copy the value of a pointer to an object that does not exist anymore. This is the case regardless whether it had pointed to or into a stack or a heap object.)
In C, there is no way to express library ownership of a pointer. So, in C there is always potential for confusion about ownership.
I give you one advice: Think twice before writing this way again. You are not putting enough effort into understanding what I'm trying to say, and coming across as an arrogant prick.
https://news.ycombinator.com/item?id=31494099
Admittedly, I didn't make my point sufficiently clear, but this isn't even about being right or wrong. (And, once more, I understand what you say. Stop belittling me.)
I'm not saying that it has to be this way, but there is a reason why something like unique_ptr (that can be quite tedious to use in my experience) has become so popular in many projects - IMO it is overused, often leading to more typing work instead of less.
If one is sufficiently used to this way of modelling, it can come as a surprise that memory management needn't be so hard, and doesn't require smart pointers or anything, if the program design (global flow of data etc.) is sufficiently clear.
With the C++ approach I've found myself overthinking the problem many times. But with the insight that pointers are just data, and memory management can be independent, it turns out that programming with raw pointers need not be hard. There is no problem passing a pointer without "move semantics" shenanigans.