Bug 169601 – Fix uninitialized public members in Webkit2/Shared

• Status: NEW
• Component: WebKit2

[Tomas Popela]

Found by Coverity scan.

[Tomas Popela]

Created attachment 304375 [details]
Patch

[Build Bot]

Comment on attachment 304375 [details]
Patch

Attachment 304375 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/3320602

Number of test failures exceeded the failure limit.

[Build Bot]

Created attachment 304382 [details]
Archive of layout-test-results from ews105 for mac-elcapitan-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105  Port: mac-elcapitan-wk2  Platform: Mac OS X 10.11.6

[Tomas Popela]

Created attachment 304793 [details]
Patch

Correct the patch (after I previously had some problems with webkit-patch).

[Michael Catanzaro]

Ping owners

[Alexey Proskuryakov]

I'm still very much unsure if this is desirable, as it makes it harder to find uninitialized variable issues with UBSan.

[Maciej Stachowiak]

Comment on attachment 304793 [details]
Patch

Where these fields found to ever actually be used uninitialized, or is this a "just in case"? I think on the whole it's better to initialize these. Unfortunately, this patch no longer applies, so r- for current version.

[Michael Catanzaro]

I'm really skeptical that leaving variables initially uninitialized at runtime is a good way to "debug" failure to initialize them to some specific value later, given this makes the code significantly less robust.

In this case, the goal was to resolve various warnings from Coverity. WebKit would probably benefit significantly from an effort to get our Coverity results into better shape. Sadly, that requires significant time and effort....