problem converting UTF-16 and my extension

Posted by half_a_cup on 2009-03-05 15:25

I'm working on a Komodo extension with a module written in C++. I compiled it with the libraries from Firefox 3.0.4 (because it has mozilla version and Komodo seems to have I can't seem to convert UTF-16 strings to UTF-8 using the XPCOM library. I've tried NS_ConvertUTF16toUTF8(str).get(), ToNewUTF8String(nsDependentString(str)) and NS_StringGetData(nsDependentString(str),&buffer) and they all resulted in a NULL pointer (NS_ConvertUTF16toUTF8(str).Length() returns zero). The string came from a test macro written in javascript that uses my XPCOM object, so there is no reason for the source string to be a problem and debugging the module confirms that it receives what would be "t\0o\0_\0d\0e\0b\0u\0g\0.\0c\0p\0p\0\0\0" if cast to char*.

Here are the relevant files (compiled for x86 linux):

(note that if you try to use the module, it currently doesn't check for NULL output from those functions and subsequently crashes Komodo, so don't try to use it if you have unsaved files.)

Since I'm already sharing it, I may as well explain what I'm working on. I'm working on an extension that allows Komodo to compile and debug C++ programs. Later I might add C support and see if I can add intelligent autocomplete support. The extension is essentially a front-end to gcc and gdb.

In the extension, build.js does the compiling. Currently it uses all source files found in the project directory. It will instead use only the source files that are part of the project when I figure out how. It calls gcc -MM to determine source file dependancies and only compiles/links targets if the dependant files are newer or the targets do not exist. implements koIDBGPSession and communicates with a gdb process using the GDB/MI interface. It is intended to be something that can be passed to Komodo in place of one of its other debuggers and have everything work the same. Then I'll need to create a new interface inheriting from koIDBGPSession to add support for things that only make sense for compiled programs like viewing disassembly.

half_a_cup | Fri, 2009-03-06 16:24

After updating my error handling I realised a more important function is failing earlier. NS_GetComponentManager is returning NS_ERROR_NOT_INITIALIZED.

ActiveState Staff
Fri, 2009-03-06 16:41

I think that usually indicates that your module is not being registered correctly.

Try turning on the logging of the component manager as well (NSPR_LOG_MODULES=nsNativeModuleLoader:5), to see what's going on:


half_a_cup | Fri, 2009-03-06 18:05

-134891696[83a0a08]: nsNativeModuleLoader::LoadModule("/home/rouslan/.komodoide/5.0/host-rouslan/XRE/extensions/cppsupport@nowhere/components/") - Success

Registration doesn't seem to be an issue. NS_GetComponentManager is called in the constructor of my object, which is called after I execute the following in javascript:

half_a_cup | Sat, 2009-03-07 01:59

I finally have it solved. I had to link against xpcomglue_s instead of xpcomglue (which after looking at the Firefox autoconf files appears to be for linking to the non-standalone version of the glue library, which one would think is also the non-static version, so it's odd that it gets the "_s" and not the other).