Are these two activeBackend and defaultBackend variables associated with only custom handles the user adds ?

No, they've always been there. In fact af_get_active_backend and af::setBackend(AF_BACKEND_DEFAULT) uses those variables. They're not currently being initialized, so I thought why not initialize them too as a good practice. They're actually being set in the AFSymbolManager constructor definition though. I can revert this change though if you think we should leave them not value-initialized.

The reason I asked this is, default backend or active backend are automatically chosen if not set by user. So, I am concerned if we will mess that up by setting it to CPU here by default. Can you please verify that.

To avoid confusion, lets assign that to AF_BACKEND_DEFAULT instead of CPU.

Yes I can verify that it will choose whatever the AFSymbolManager constructor definition determines as the default backend (by the order of CUDA, OpenCL, and CPU) if the user does not explicitly call af::setBackend.

I think your suggestion that we initialize it to to AF_BACKEND_DEFAULT instead is fine. I see no problems with activeBackend and defaultBackend being initialized to that in any cases. If there's at least one backend available, both activeBackend and defaultBackend will be set to the determined default backend as per the order, and if there are no backends available, they will be both set to AF_BACKEND_DEFAULT, which I don't think will pose a problem - any arrayfire calls would just fail as expected, unless af_add/set_backend_library are called.