Bug #15882


panic_quiesce and panic_dump are uninitialised

Added by Thirteen Oxide 18 days ago. Updated 3 days ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


All the other non-static globals in os/panic.c are initialised. These aren't, and if something guarantees that they are initialised to zero I don't know what it is. They have never been initialised nor have they ever been static (since 2005 anyway). They do appear to be 0 in unix but again I don't know anything that guarantees this and if some other value were present at that location we would hang on panic without creating a dump.

Actions #1

Updated by Thirteen Oxide 18 days ago

Well, then. A colleague gently suggested I go back and look at the standard. I did (C11, specifically ISO/IEC 9899:201x draft N1570, April 12, 2011) and have convinced myself, probably, that all the other zero initialisers for globals are unnecessary and this isn't a defect at all. The spec is tortuous and hard to follow, but the critical points seem to be these:

6.2.2(4) tells us that globals that are declared neither static nor extern have "internal linkage". What's that mean? Glad you asked.

6.2.4(3) tells us that anything with internal linkage that isn't declared thread-local has "static duration". Note that this is so even if not declared static -- per the use of the word OR here, emphasis mine:

An object whose identifier is declared without the storage-class specifier _Thread_local, and either with external or internal linkage or with the storage-class specifier static, has static storage duration. Its lifetime is the entire execution of the program and its stored value is initialized only once, prior to program startup.

So what does "static duration" mean? Again, glad you asked.

6.7.9(10) is the payoff. It tells us:

If an object that has static or thread storage duration is not initialized explicitly, then: ... if it has arithmetic type, it is initialized to (positive or unsigned) zero; ...

It goes on to tell us that other types are initialised to things that are also 0.

It's difficult to be 100% certain that I've read this correctly because there's a lot of other text that uses similar words; that is, I'm not absolutely sure that I've followed the correct chain of definitions and not some other chain that would lead to a wildly different conclusion. If anyone else comes along and reads the spec the same way, that person should probably close this as not a defect.

Actions #2

Updated by Thirteen Oxide 3 days ago

  • Status changed from New to Rejected

Closing, as the generated binary is clearly fine and the most obvious reading of the standard suggests this isn't a real problem.


Also available in: Atom PDF