Fix uninitialized warning, and work around a bug in gcc over clobbering

[jhibbits]

Summary

r329077 caused gcc to emit uninitialized use warnings. Attempting to
fix those warnings yielded the following warnings:

usr.bin/tftp/main.c: In function 'main':
usr.bin/tftp/main.c:181: warning: variable 'el' might be clobbered by 'longjmp' or 'vfork'
usr.bin/tftp/main.c:182: warning: variable 'hist' might be clobbered by 'longjmp' or 'vfork'

This is a known bug in gcc, found at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24239

Work around that by simply marking hist and el as static.

Test Plan

Compiled only

[imp]

seems legit. Though if you make them STATIC you shouldn't need to also initialize them to NULL because that's automatic.

[jhibbits]

In D14302#299866, @imp wrote:

seems legit. Though if you make them STATIC you shouldn't need to also initialize them to NULL because that's automatic.

Yup, I realized that immediately after I posted the review, so removed and test-built for success.

[cem]

I already the change of initializing them running through universe :-/.

I think we should prefer initialization to unneeded static locals.

OTOH, GCC4.2 is too dumb to handle that, too. So, static is fine, I guess.

[jhibbits]

In D14302#299914, @cem wrote:

I already the change of initializing them running through universe :-/.

Unfortunately initialization isn't sufficient for GCC.

I think we should prefer initialization to unneeded static locals.

I would much rather this as well, but GCC doesn't like that. That said, does tftp *really* need setjmp()/longjmp()? It seems to be a hacky way to handle one signal.

OTOH, GCC4.2 is too dumb to handle that, too. So, static is fine, I guess.

GCC 4.2 needs to burn in a fire. Unfortunately, the bug also exists even in GCC 8 according to the bug dup'd against it, and the devs just don't seem to care.

[cem]

In D14302#299926, @jhibbits wrote:

Unfortunately initialization isn't sufficient for GCC.

Yes. At least the plan of record is we ditch GCC4.2 in 13. That will be nice.

That said, does tftp *really* need setjmp()/longjmp()? It seems to be a hacky way to handle one signal.

It almost certainly does not. I just wanted to make the minimal change to fix the PR, not spend much time cleaning up tftp. Feel free to restructure it, though.

GCC 4.2 needs to burn in a fire. Unfortunately, the bug also exists even in GCC 8 according to the bug dup'd against it, and the devs just don't seem to care.

GCC8 might not have the first uninitialized variable warning?

OTOH, leaving them static is fine. If they're static I would consider moving them outside to file scope, except they would need to be renamed.

[emaste]

Yes. At least the plan of record is we ditch GCC4.2 in 13. That will be nice.

In fact it will likely be gone in 12. Progress is being made on migrating tier-2 architectures to in-tree Clang or external toolchain.