RESOLVED FIXED Bug 24538
class/struct mixup in forward declarations
https://bugs.webkit.org/show_bug.cgi?id=24538
Summary class/struct mixup in forward declarations
Norbert Leser
Reported 2009-03-11 19:28:21 PDT
There are several class/struct mix-ups in forward declarations. Symbian compilers (i.e., the linkers) fail with unresolved references. Proposed solution is to fix the wrong qualifier in the respective implementation files. See attached patch.
Attachments
Proposed fix for bug 24538 (4.39 KB, patch)
2009-03-11 19:29 PDT, Norbert Leser
no flags
Revised patch for bug 24538 (4.93 KB, patch)
2009-05-11 14:43 PDT, Norbert Leser
darin: review+
Norbert Leser
Comment 1 2009-03-11 19:29:00 PDT
Created attachment 28514 [details] Proposed fix for bug 24538
Mark Rowe (bdash)
Comment 2 2009-03-11 19:35:04 PDT
Comment on attachment 28514 [details] Proposed fix for bug 24538 The ResourceRequest change isn't obviously correct, as ResourceRequest is declared as a struct on some platforms, but class on others. That should probably be made consistent as there's a chance that changing it from class to struct will break other platform's builds.
Norbert Leser
Comment 3 2009-03-13 10:45:31 PDT
(In reply to comment #2) > (From update of attachment 28514 [details] [review]) > The ResourceRequest change isn't obviously correct, as ResourceRequest is > declared as a struct on some platforms, but class on others. That should > probably be made consistent as there's a chance that changing it from class to > struct will break other platform's builds. > I understand that this could potentially be an issue with other platforms. However, apparently it is not, because ResourceRequest is forward declared both as class and as struct across WebCore (e.g., xml/XMLHttpRequest.h, network/ResourceHandleClient.h, ... use struct). There are only 2 non-platform specific places where it is declared as "class". I suggest to make it consistent throughout WebCore. -- One place is in loader/appcache/ApplicationCache.h, as proposed in my patch. -- The 2nd place is wml/WMLGoElement.h. That's not included in my patch because I don't have the means of regression testing that code path. Still, if you can verify that, it would be cleaner to also make that change.
Eric Seidel (no email)
Comment 4 2009-05-11 05:55:25 PDT
Comment on attachment 28514 [details] Proposed fix for bug 24538 Is this still a problem? Most of these get fixed rather quickly as these are errors on windows...
Norbert Leser
Comment 5 2009-05-11 14:43:00 PDT
Created attachment 30204 [details] Revised patch for bug 24538 As response to Eric's question: Yes, the reported issue still exists in multiple places. The attached patch is an update, based on current code (rev 43416).
Darin Adler
Comment 6 2009-05-11 17:01:36 PDT
Note You need to log in before you can comment on or make changes to this bug.