Returning null instead of empty string if a wrapped function returns null pointer

[suzukieng]

Hi emscripten folks,

I am trying to wrap a function with the following C signature:

const char* getLastError()

It returns a pointer to zero-terminated C string or the NULL pointer in case no last error exists.

Wrapping the function in emscripten using Module.cwrap('getLastError', 'string', []) yields a function that returns the empty string if the wrapped function returns NULL, which was a bit surprising to me.

What is the rationale for returning the empty string instead of JS null in this case?

Thanks!

[sbc100]

That sounds like the correct behaviour yes. Would you have time to send a PR? I think the code in question is in src/library_ccall.js

[sbc100]

Actually it looks like there is already handling for this case:

emscripten/src/library_ccall.js

Lines 33 to 38 in 645750c

	var ret = 0;
	if (str !== null && str !== undefined && str !== 0) { // null string
	// at most 4 bytes per UTF-8 code point, +1 for the trailing '\0'
	ret = stringToUTF8OnStack(str);
	}
	return {{{ to64('ret') }}};

It looks like it should return 0 if getLastError returns NULL/0.

[sbc100]

Sorry thats the handler to argument. The handler for returned strings just calls UTF8ToString which for some reason does, as you say, return empty string instead of null:

emscripten/src/library_strings.js

Line 126 in 645750c

if (!ptr) return '';

I wonder how much stuff would break if we changed that to return null instead.

CC @brendandahl @kripken @juj

[suzukieng]

Thanks for responding so quickly, Sam, I really appreciate it.

I agree that changing the behavior of UTF8ToString is probably not worth the effort considering the possible breakage of downstream code. Rewriting the empty string to null in the return handler would also not make much sense IMHO, since the empty string is a legitimate string to return.

I was primarily wondering if this is a conscious design choice or just something that turned out the way it is for reasons unknown.

[sbc100]

I think this is likely an historcal accident.

[kripken]

I agree changing this is probably not worth it. I'm not sure why it is the way it is, but likely the early users of the function preferred it that way, or it didn't matter.

[sbc100]

I'd still like to try and make this change if we can.. not sure if there is way to do it in a backwards compatible way..