[Backport v4.3-branch] drivers: xen: Fix uninitialized variable warning

[github-actions]

Backport 139b7c2 from #100737.

Fixes #101048

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jhedberg]

@aescolar @firscity this needs a bug report

[firscity]

@aescolar I'm a little bit confused by this, as I can see in #100737 and in logs CI was not happy with 2 variables uninitialized:

      zephyr/CMakeFiles/zephyr.dir/drivers/xen/gnttab.c.obj
In file included from include/zephyr/logging/log.h:11,
                 from drivers/xen/gnttab.c:31:
include/zephyr/logging/log_core.h: In function 'gnttab_get_pages':
include/zephyr/logging/log_core.h:221:9: warning: 'gfn' may be used
uninitialized [-Wmaybe-uninitialized]
  221 |         z_log_minimal_printk("%c: " fmt "\n", \
      |         ^~~~~~~~~~~~~~~~~~~~
drivers/xen/gnttab.c:202:19: note: 'gfn' was declared here
  202 |         xen_pfn_t gfn;
      |                   ^~~
include/zephyr/logging/log_core.h:221:9: warning: 'ret' may be used
uninitialized [-Wmaybe-uninitialized]
  221 |         z_log_minimal_printk("%c: " fmt "\n", \
      |         ^~~~~~~~~~~~~~~~~~~~
drivers/xen/gnttab.c:199:13: note: 'ret' was declared here
  199 |         int ret;
      |             ^~~

But the only ret was fixed by you. Is CI happy now?
I have doubts for both of them, current function flow has no chance to use them uninitialized, but still it is OK to initialize them on declaration. I just need to clarify if initialization of ret helped to fix the CI issue with gfn also. If so - it becomes much more odd...

[aescolar]

@aescolar I'm a little bit confused by this, as I can see in #100737 and in logs CI was not happy with 2 variables uninitialized:
...
But the only ret was fixed by you. Is CI happy now?

Yes.
The warning for non-itialiazed gfn was in the 229-240 block, which depends on ret != 0.
The compiler seemed to be happy with either initializing ret to 0, or moving that block into line 224 just before the break.
It really seemed the compiler issue was with the possibility of the for loop being skipped. But if ret is initialized to 0, that lower if block is also skipped as it should.