[webkit-dev] strdup in WebKit
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 fastFree. The following source files in WebCore contains strdup calls. dom/XMLTokenizerLibxml2.cpp plugins/PluginStream.cpp platform/network/ResourceHandleInternal.h platform/network/curl/ResourceHandleManager.cpp platform/network/curl/ResourceHandleCurl.cpp xml/XSLTProcessorLibxslt.cpp bindings/v8/npruntime.cpp bindings/v8/V8NPUtils.cpp bridge/IdentifierRep.h bridge/jni/jni_runtime.cpp bridge/jni/jsc/JavaClassJSC.cpp bridge/npruntime.cpp bridge/testbindings.cpp strdup/free pairs can be safely replaced with fastStrDup/fastFree in most cases. However, bridge and bindings can be an exception because some APIs must return malloc() allocated memory that can be freed with free(). I am asking this because strdup (POSIX function) is not available in RVCT. If this is not possible for some reasons, adding strdup to StringExtras.h for RVCT can be a good solution too. How does the Symbian QT port solve this problem? Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] strdup in WebKit
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 fastMalloc? The memory returned by fastStrDup can be freed by fastFree. Sounds like a reasonable plan in general. It's possible that in some of the cases you cie below, strdup is being used to pass malloc-allocated memory to a library that expects a string allocated with system malloc, which it will proceed to free itself. I'm not sure if it's really true in any of these cases, but it's something to check. I suggest filing a bug and submitting a patch for this. Cheers, Maciej The following source files in WebCore contains strdup calls. dom/XMLTokenizerLibxml2.cpp plugins/PluginStream.cpp platform/network/ResourceHandleInternal.h platform/network/curl/ResourceHandleManager.cpp platform/network/curl/ResourceHandleCurl.cpp xml/XSLTProcessorLibxslt.cpp bindings/v8/npruntime.cpp bindings/v8/V8NPUtils.cpp bridge/IdentifierRep.h bridge/jni/jni_runtime.cpp bridge/jni/jsc/JavaClassJSC.cpp bridge/npruntime.cpp bridge/testbindings.cpp strdup/free pairs can be safely replaced with fastStrDup/fastFree in most cases. However, bridge and bindings can be an exception because some APIs must return malloc() allocated memory that can be freed with free(). I am asking this because strdup (POSIX function) is not available in RVCT. If this is not possible for some reasons, adding strdup to StringExtras.h for RVCT can be a good solution too. How does the Symbian QT port solve this problem? Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Qtish API for JavaScriptCore, take two
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 upstream (we don't want to limit the freedom to change the JSC implementation by introducing new dependencies). Hence, we've started an implementation that only uses the C API. The latest version of the initial patch can be found in the Bugzilla task: https://bugs.webkit.org/show_bug.cgi?id=32565 It provides only the basic functionality of the two main classes, QScriptEngine and QScriptValue. If the community agrees, we would like to begin the process of upstreaming this and other patches, that incrementally build the C++ API on top of the C API. If there are places where we find the C API to be incomplete, we will try to propose and implement additional API that will hopefully also be of value to other JavaScriptCore embedders. On behalf of the Qt developers, Kent [1] https://lists.webkit.org/pipermail/webkit-dev/2009-August/009610.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Tagging bug names with a platform name: limit to platform-specific patches
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 change is only for the benefit of a signle platform, I suggest we not use the platform name prefix. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] strdup in WebKit
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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Font layout features
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 so are using Cairo font layout. Can someone comment on what limitation we may have with Asian fonts/glyphs or other issues with this configuration? We have ported the latest versions of freetype, fontconfig and cairo to CE. Thanks, Jason. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Qtish API for JavaScriptCore, take two
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 JavaScriptCore [1]. The fundamental issue back then was that our implementation was not using the JavaScriptCore C API, which made it problematic to upstream (we don't want to limit the freedom to change the JSC implementation by introducing new dependencies). Hence, we've started an implementation that only uses the C API. The latest version of the initial patch can be found in the Bugzilla task: https://bugs.webkit.org/show_bug.cgi?id=32565 It provides only the basic functionality of the two main classes, QScriptEngine and QScriptValue. If the community agrees, we would like to begin the process of upstreaming this and other patches, that incrementally build the C++ API on top of the C API. If there are places where we find the C API to be incomplete, we will try to propose and implement additional API that will hopefully also be of value to other JavaScriptCore embedders. On behalf of the Qt developers, Kent [1] https://lists.webkit.org/pipermail/webkit-dev/2009-August/009610.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Qtish API for JavaScriptCore, take two
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 JavaScriptCore C API, which made it problematic to upstream (we don't want to limit the freedom to change the JSC implementation by introducing new dependencies). Hence, we've started an implementation that only uses the C API. The latest version of the initial patch can be found in the Bugzilla task: https://bugs.webkit.org/show_bug.cgi?id=32565 It provides only the basic functionality of the two main classes, QScriptEngine and QScriptValue. If the community agrees, we would like to begin the process of upstreaming this and other patches, that incrementally build the C++ API on top of the C API. If there are places where we find the C API to be incomplete, we will try to propose and implement additional API that will hopefully also be of value to other JavaScriptCore embedders. This sounds like a good approach. And keeping it in the WebKit repository seems totall acceptable to me. Also please let us know if you find any limitations in the C API that make it hard or impossible to do what you want with this API - we would like to fix any such issues. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit style for switch statement
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 least for most source code)
for a switch statement is like this:
switch (var) {
case valueFirst:
...
break;
...
case valueLast:
...
break;
default:
ASSERT_NOT_REACHED()
}
This looks good. But some compilers may give a warning like: statement is
unreachable. Disabling this warning is a solution. But this warning can
be helpful in some cases.
So, how about changing the webkit style to this?
switch (var) {
case valueFirst:
...
break;
...
default:
ASSERT(var == valueLast);
...
break;
}
-Yong
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit style for switch statement
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 not the preferred style. The preferred style (not counting indenting,
which was only recently standardized) can be seen in functions like
Node::isContainer. To take advantage of the warning GCC provides to help you
make sure you cover all values of an enum, we leave out the default whenever
possible.
Could you give a specific example in today’s WebKit code where a particular
compiler is emitting a “not reached” warning?
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit style for switch statement
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
Re: [webkit-dev] Tagging bug names with a platform name: limit to platform-specific patches
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 to one particular platform’s code. If the patch changes more than a trivial bit of platform-independent code, even if the change is only for the benefit of a signle platform, I suggest we not use the platform name prefix. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tagging bug names with a platform name: limit to platform-specific patches
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 than a trivial bit of platform-independent code, even if the change is only for the benefit of a signle platform, I suggest we not use the platform name prefix. Makes sense to me. I would also like to suggest that people should *not* use the bracket convention for things besides platform, like [dom] or [style-queue]. Some people (e.g. me) use queries to split bracket-prefix patches into a separate list, and it's better not to hide general-purpose patches. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
