criu/filesystems.c: refactor binfmt_misc_restore_bme
criu/filesystems.c: refactor binfmt_misc_restore_bme

The following error is emitted by clang:

>   CC       criu/filesystems.o
> criu/filesystems.c:280:13: error: variable 'ret' is used uninitialized
>    whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
>         } else if (bme->extension) {
>                    ^~~~~~~~~~~~~~
> criu/filesystems.c:287:6: note: uninitialized use occurs here
>         if (ret > 0) {
>             ^~~
> criu/filesystems.c:280:9: note: remove the 'if' if its condition is
>    always true
>         } else if (bme->extension) {
>                ^~~~~~~~~~~~~~~~~~~~
> criu/filesystems.c:272:9: note: initialize the variable 'ret' to silence
>    this warning
>         int ret;
>                ^
>                 = 0
> 1 error generated.

This code was a result of commit 398e7d3.

If we look closely, this is a false alarm, as "else if (bme->extension)"
is always true as it was checked before. But this is not very clear,
and the issue with clangs still needs to be fixed.

There are many ways to do so:

1. Initialize ret to 0. This is what initial version of this patch did.

2. Remove the always-true condition, like this:

	-	} else if (bme->extension) {
	+	} else {

In my opinion this would hurt readability.

3. Change the code flow, improving readability at the same time.

I believe that #3 is what this patch does. In addition, it fixes
handling of a few corner cases:

- an overflow in snprintf();
- a case when bme->name is NULL (as it is used for strlen/snprintf,
  there is a potential for SIGSEGV);
- a case of ret == 0 (currently there is no code flow that
  results in ret being 0, so it's just for the future).

[v2: use linux kernel style for 'else' after a block]
[xemul: Fix // comments ]

Cc: Kirill Tkhai <e5b39230c99b4d3ebd6aa54f6d823f95134bc39d@virtuozzo.com>
Signed-off-by: Kir Kolyshkin <c0159612b0ef32139322233232df1a0d189c4b9b@openvz.org>
Acked-by: Kirill Tkhai <e5b39230c99b4d3ebd6aa54f6d823f95134bc39d@virtuozzo.com>
Signed-off-by: Pavel Emelyanov <c9a32589e048e044184536f7ac71ef92fe82df3e@virtuozzo.com>

eabatalov/criu,eabatalov/criu,eabatalov/criu,eabatalov/criu,eabatalov/criu,eabatalov/criu