My code fails and I guess the reason is I have a slice to data in the
stack and it becomes garbage in some moment. So I need a way to check
where data is placed. Is it right that it can be done in linux using
`sbrk` so that if the addr of data is less than `sbrk(0)` returning then
data is on the stack and on the heap in other case?

My code fails and I guess the reason is I have a slice to data
in the stack and it becomes garbage in some moment. So I need a
way to check where data is placed. Is it right that it can be
done in linux using `sbrk` so that if the addr of data is less
than `sbrk(0)` returning then data is on the stack and on the
heap in other case?

The second is wrong. You are asserting that the storage of p is not on
the stack, but it is.
What p *points at* is not on the stack.
So the correct call should be:
assert(!(*p).onStack);
or (IMO) less ugly: assert(!onStack(*p));
-Steve

The second is wrong. You are asserting that the storage of p is
not on the stack, but it is.
What p *points at* is not on the stack.
So the correct call should be:
assert(!(*p).onStack);
or (IMO) less ugly: assert(!onStack(*p));
-Steve

you misunderstood, the code is from biotronic's post, i just made
a static array of 5kb to point out how it fails, in just one way
out of a dozen other possibilities.

The second is wrong. You are asserting that the storage of p is
not on the stack, but it is.
What p *points at* is not on the stack.
So the correct call should be:
assert(!(*p).onStack);
or (IMO) less ugly: assert(!onStack(*p));
-Steve

It's worth pointing out, btw, that the main reason for this code
is to help drug diagnose his or her problem, not to be the
be-all, end-all of stack identifying functions. :)
It will of course not correctly identify pointers to variables on
other threads' stacks, and fiber stacks probably trip it up bad.
--
Biotronic

My code fails and I guess the reason is I have a slice to data in the
stack and it becomes garbage in some moment. So I need a way to check
where data is placed. Is it right that it can be done in linux using
`sbrk` so that if the addr of data is less than `sbrk(0)` returning then
data is on the stack and on the heap in other case?

In theory, safe is supposed to help with this such that any code that
sliced a static array would be system or trusted, which would seriously
narrow down the search space when something goes wrong with memory, but the
slicing of static arrays typically being treated as safe is one of the
major, outstanding bugs for safe. It looks like it's now caught when simply
returning a slice of a static array, but simply slicing a static array is
still considered safe (even though taking the address of a local variable
does, and it's really the same thing).
So, if you try and use safe throughout your code, you'll find _some_ of the
potential memory problems but not all of them. All of the work that Walter
has been doing with DIP 1000 should help though.
- Jonathan M Davis