[Webkit-unassigned] [Bug 24932] WebKit compilation support in Solaris 10 with Sun Studio 12 (CC 5.9)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=24932





--- Comment #38 from Thiago Macieira <thiago.macieira at nokia.com>  2009-07-28 09:02:48 PDT ---
Patches 2, 3, 7, 10, and 16 are fixes to compiler limitations or bugs. Those
are the only that I would agree to keeping in a separate branch. In special,
patches 2 and 3 are required for some other compilers without alignof and
aligned support (IBM xlC for example).

Patch 4 should be accepted because code using time_t should #include
<sys/time.h>. It should not depend on that file coming via indirect include
(like #include <memory>). I even wonder how WebKit compiles with gcc 4.4 and
glibc 2.10 on Linux, which have done a great deal of work cleaning up indirect
includes.

Patch 5 should be accepted because misaligned reads aren't allowed on this
processor, and the change just makes sense.

Patch 6 should be accepted because it's a ticking timebomb for other compilers
as well. The fact that the compiler did not inline in the current version
doesn't mean future versions won't have the same problem. Even the same
versions of the compiler could inline depending on how WebKit code changes in
the future.

Patch 8 uses is a simple fix for where Solaris deviates from POSIX
(http://www.opengroup.org/onlinepubs/9699919799/functions/mmap.html), but is
innocuous since char* can be cast to void*.

Patch 9 seems to be just the compiler being stricter. It also makes sense
because it appears to be what is intended anyway.

Patch 11 is formalism: the element being moved is deleted. It should not be
passed as a const parameter.

Patch 12 is pedantism. The patch isn't strictly necessary, since WebKit
compiles without, but other compilers are stricter than SunCC (for example,
HP's aCC does not allow terminating commas). In fact, there are a couple of
other places where I didn't apply the change (pcre and JSC's Opcode.h), but
will need the fix if WebKit is to compile with aCC.

Patches 13, 14, and 15, as far as I know, are required per the standard: the
second and third arguments of ?: must be of the same type.

Patch 17 is "anachronism": the fact that the calling sequence for C++ functions
is the same as C is a coincidence, but is not required by the standard. It
could be that this is just a bug that the compiler decided to decorate the
function instead of exporting it as extern "C", but this should be technically
used. In fact, you should never pass a static member function to a C callback.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.