Initialise global and static variable to 0 is always unnecessary.
Remove the unnecessary initialisations.
Signed-off-by: Jason Wang <[email protected]>
---
arch/powerpc/kexec/core_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
index c2bea9db1c1e..2407214e3f41 100644
--- a/arch/powerpc/kexec/core_64.c
+++ b/arch/powerpc/kexec/core_64.c
@@ -135,7 +135,7 @@ notrace void kexec_copy_flush(struct kimage *image)
#ifdef CONFIG_SMP
-static int kexec_all_irq_disabled = 0;
+static int kexec_all_irq_disabled;
static void kexec_smp_down(void *arg)
{
--
2.35.1
Hello,
On Sat, Jul 23, 2022 at 05:24:36PM +0800, Jason Wang wrote:
> Initialise global and static variable to 0 is always unnecessary.
> Remove the unnecessary initialisations.
Isn't this change also unnecessary?
Initializing to 0 does not affect correctness, or even any kind of
semantics in any way.
The current code is slightly easier to understand.
And changing the code introduces history noise for na gain.
Thanks
Michal
>
> Signed-off-by: Jason Wang <[email protected]>
> ---
> arch/powerpc/kexec/core_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
> index c2bea9db1c1e..2407214e3f41 100644
> --- a/arch/powerpc/kexec/core_64.c
> +++ b/arch/powerpc/kexec/core_64.c
> @@ -135,7 +135,7 @@ notrace void kexec_copy_flush(struct kimage *image)
>
> #ifdef CONFIG_SMP
>
> -static int kexec_all_irq_disabled = 0;
> +static int kexec_all_irq_disabled;
>
> static void kexec_smp_down(void *arg)
> {
> --
> 2.35.1
>
On Sat, Jul 23, 2022 at 03:34:05PM +0200, Michal Such?nek wrote:
> Hello,
>
> On Sat, Jul 23, 2022 at 05:24:36PM +0800, Jason Wang wrote:
> > Initialise global and static variable to 0 is always unnecessary.
> > Remove the unnecessary initialisations.
>
> Isn't this change also unnecessary?
>
> Initializing to 0 does not affect correctness, or even any kind of
> semantics in any way.
It did make a difference when the kernel was still compiled with
-fcommon (which used to be the GCC default on most configurations, it is
traditional on Unix). No explicit initialiser puts an object in .bss if
you use -fcommon. This matters a bit for data layout.
> The current code is slightly easier to understand.
>
> And changing the code introduces history noise for na gain.
Yup.
This does give you some code golf points of course ;-)
Segher
Segher Boessenkool <[email protected]> writes:
> On Sat, Jul 23, 2022 at 03:34:05PM +0200, Michal Suchánek wrote:
>> Hello,
>>
>> On Sat, Jul 23, 2022 at 05:24:36PM +0800, Jason Wang wrote:
>> > Initialise global and static variable to 0 is always unnecessary.
>> > Remove the unnecessary initialisations.
>>
>> Isn't this change also unnecessary?
>>
>> Initializing to 0 does not affect correctness, or even any kind of
>> semantics in any way.
>
> It did make a difference when the kernel was still compiled with
> -fcommon (which used to be the GCC default on most configurations, it is
> traditional on Unix). No explicit initialiser puts an object in .bss if
> you use -fcommon. This matters a bit for data layout.
The kernel has built with -fno-common since ~2002.
I think the belief is that an explicit initialiser of 0 forces the
variable into .data, but AFAICS that is not true with any compiler we
support.
cheers
On Mon, Jul 25, 2022 at 01:27:52PM +1000, Michael Ellerman wrote:
> Segher Boessenkool <[email protected]> writes:
> > On Sat, Jul 23, 2022 at 03:34:05PM +0200, Michal Such?nek wrote:
> >> Hello,
> >>
> >> On Sat, Jul 23, 2022 at 05:24:36PM +0800, Jason Wang wrote:
> >> > Initialise global and static variable to 0 is always unnecessary.
> >> > Remove the unnecessary initialisations.
> >>
> >> Isn't this change also unnecessary?
> >>
> >> Initializing to 0 does not affect correctness, or even any kind of
> >> semantics in any way.
> >
> > It did make a difference when the kernel was still compiled with
> > -fcommon (which used to be the GCC default on most configurations, it is
> > traditional on Unix). No explicit initialiser puts an object in .bss if
> > you use -fcommon. This matters a bit for data layout.
>
> The kernel has built with -fno-common since ~2002.
2001, yes (255649c18287). And before that it was important to
initialise everything with static storage duration explicitly in the
source code. It was part of the collective memory, I wondered if this
patch originated that way?
> I think the belief is that an explicit initialiser of 0 forces the
> variable into .data, but AFAICS that is not true with any compiler we
> support.
Exactly, you get identical code either way, if you use -fno-common.
People will still see this difference if they use a compiler before
GCC 10 for compiling most other things though.
Segher