On Tue, 8 Sep 2020 at 10:56, Tom Lane wrote:
>
> So that's good. However, a similar experiment with returning from inside
> a PG_TRY does *not* produce a warning. I suspect maybe the compiler
> throws up its hands when it sees sigsetjmp?
>
I find that odd myself, given that in PG_TRY() we:
Craig Ringer writes:
> Example here:
> https://github.com/ringerc/scrapcode/tree/master/c/clang_return_stack_checks
> So I find that actually, the __attribute__((callback(fn)) approach is
> unnecessary for the purpose proposed.
I tested this by injecting some faults of the described sort.
diff
On Fri, 4 Sep 2020 at 14:55, Craig Ringer wrote:
> Using a test program:
>
> return_stack_escape.c:14:3: warning: Address of stack memory associated
> with local variable 'g' is still referred to by the global variable
> 'guard_ptr' upon returning to the caller. This will be a dangling
On Fri, 4 Sep 2020 at 14:13, Craig Ringer wrote:
>
> I actually had a pretty good look around for static analysis options to
> see if I could find anything that might help us out before I landed up with
> this approach.
>
Apparently not good enough.
On Thu, 3 Sep 2020 at 22:28, Tom Lane wrote:
> Craig Ringer writes:
> > The attached patch series adds support for detecting coding errors where
> a
> > stack-allocated ErrorContextCallback is not popped from the
> > error_context_stack before the variable leaves scope.
>
> So my immediate
Craig Ringer writes:
> The attached patch series adds support for detecting coding errors where a
> stack-allocated ErrorContextCallback is not popped from the
> error_context_stack before the variable leaves scope.
So my immediate thoughts about this are
(1) It's mighty invasive for what it
Hi folks
The attached patch series adds support for detecting coding errors where a
stack-allocated ErrorContextCallback is not popped from the
error_context_stack before the variable leaves scope.
With the attached patches this code will emit a backtrace and abort() on
cassert builds at the
