Hi,
WebKit does not use malloc/free directly in favor of fastMalloc/fastFree.
The only exception to this rule is strdup() which returns a memory that must
be freed by free. Why don't we add fastStrDup which allocates a memory with
fastMalloc? The memory returned by fastStrDup can be freed by
On Jan 20, 2010, at 2:07 AM, KwangYul Seo wrote:
Hi,
WebKit does not use malloc/free directly in favor of fastMalloc/fastFree. The
only exception to this rule is strdup() which returns a memory that must be
freed by free. Why don't we add fastStrDup which allocates a memory with
Hello WebKit developers,
A while ago, we, the team of Qt developers at Nokia and INdT, presented
the idea of adding a Qt C++ API on top of JavaScriptCore [1].
The fundamental issue back then was that our implementation was not
using the JavaScriptCore C API, which made it problematic to
Hi folks.
We’ve never formalized this, but I believe that patches tagged with a
particular platform name such as
[Qt] Add new API for fluffy bunnies
should be limited to one particular platform’s code. If the patch changes more
than a trivial bit of platform-independent code, even if the
20.01.2010, в 02:07, KwangYul Seo написал(а):
strdup/free pairs can be safely replaced with fastStrDup/fastFree in most
cases.
Libxml2-related code in particular could use xmlStrdup for consistency.
- WBR, Alexey Proskuryakov
___
webkit-dev
As part of our port to windows CE we are using a Cairo configuration combined
with freetype. This is fairly similar to the Windows port but we are not using
the native Windows GDI/cairo layer for fonts (instead we are using cairo-ft).
However, unlike the GTK port, we did not port Pango, and
Hi Kent.
Generally speaking, I think building on top of the C API is a good idea.
Best,
Geoff
On Jan 20, 2010, at 7:08 AM, Kent Hansen wrote:
Hello WebKit developers,
A while ago, we, the team of Qt developers at Nokia and INdT, presented the
idea of adding a Qt C++ API on top of
On Jan 20, 2010, at 7:08 AM, Kent Hansen wrote:
Hello WebKit developers,
A while ago, we, the team of Qt developers at Nokia and INdT, presented the
idea of adding a Qt C++ API on top of JavaScriptCore [1].
The fundamental issue back then was that our implementation was not using the
No, we leave out the default: That allows compilers to warn when
cases are missing.
Any time you see a default: in a WebCore switch, it's sub-optimal in my opinion.
-eric
On Wed, Jan 20, 2010 at 2:19 PM, Yong Li yong.li.web...@gmail.com wrote:
As everyone may know, current webkit style (at
On Jan 20, 2010, at 2:19 PM, Yong Li wrote:
As everyone may know, current webkit style (at least for most source code)
for a switch statement is like this:
switch (var) {
case valueFirst:
...
break;
...
case valueLast:
...
break;
default:
ASSERT_NOT_REACHED()
}
That’s
Thanks, Eric, Darin. I get it.
-Yong
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Sounds like a good idea, I'm all for it.
Kenneth
On Wed, Jan 20, 2010 at 1:18 PM, Darin Adler da...@apple.com wrote:
Hi folks.
We’ve never formalized this, but I believe that patches tagged with a
particular platform name such as
[Qt] Add new API for fluffy bunnies
should be limited
On Jan 20, 2010, at 8:18 AM, Darin Adler wrote:
Hi folks.
We’ve never formalized this, but I believe that patches tagged with a
particular platform name such as
[Qt] Add new API for fluffy bunnies
should be limited to one particular platform’s code. If the patch changes
more
13 matches
Mail list logo
