On Wed, 29 Sep 1999, Mason Loring Bliss wrote:

> This might not help us find the right solution, but this miniscule patch makes
> shutdown do the right thing on my box:
> 
> *** shutdown.c  Wed Sep 29 09:37:07 1999
> --- shutdown.c.foo      Sun Sep 26 20:19:54 1999
> ***************
> *** 118,123 ****
> --- 118,125 ----
>         struct passwd *pw;
>         int arglen, ch, len;
>   
> +       dofast = 0;
> + 
>   #ifndef DEBUG
>         if (geteuid())
>                 errx(1, "NOT super-user");
> 
> 
> I'd be gratified if you could try it and tell me how it does on your box.

It's not consistent enough for me to get back to you quickly.

> The messed up thing is that this should not be necessary -
> "dofast" is supposed to be automatically initialized to zero.
> That's something we're supposed to be able to depend on.

I think you're onto something. shutdown.c in -current and 1.4.1 are
the same, and dofast is *never* *initialized*. That's bad.

> Since this patch explicitly initializes "dofast" at the start of
> the program, and since nothing else has been touched, I'm at a
> loss to point at anything other than a code generation bug, but
> I'm not quite sure how to proceed... I think I probably just need
> to learn to use a debugger to step through the thing and see
> what's happening. I suppose it wouldn't hurt to take a whack at
> staring at assembly output as well - I once, ages ago, was at
> least read-only with regard to x86 assembly code.

I looked at the m68k assembly, and egcs-1.1.1 does *not* initialize
"dofast" to zero. It goes in the data segment, so maybe we're
expecting the linker to zfod. Clearly it doesn't on current, nor would
we want it to, necessarily. You are running ld.new, so maybe there's a
difference there. In any case, an uninitialized variable is a bug!