Yes, there is a risk. This appears to be the definition of fftw_destroy_plan
in FFTW 3.3.3:
void X(destroy_plan)(X(plan) p)
{
if (p) {
X(plan_awake)(p->pln, SLEEPY);
X(plan_destroy_internal)(p->pln);
X(problem_destroy)(p->prb);
X(ifree)(p);
}
}
It uses the plan p
as a pointer. So, if p
is uninitialized, behavior not defined by the C standard results.
Even if we consider theoretical alternative implementations of FFTW rather than the actual code, there is a risk. Since the contents of myPlan
are uncontrolled, they could happen to appear identical to a valid FFTW plan, in which case fftw_destroy_plan
will attempt to destroy it. This almost certainly involves calling free
on pointers in the plan, even if we consider theoretical alternative implementations of FFT rather than the actual code.
It is theoretically possible the FFTW API might be implemented with a fixed amount of space in the plan (with fftw_plan
being a large struct
rather than a pointer), so that dynamic memory allocation is not necessary, and free
is not used. However, then there would be no need for a routine to destroy a plan. So the API design shows us it is designed with the expectation that dynamic memory allocation will be used.