Support null language for fallbackFontForChar's IPC wrapper

Support null language for fallbackFontForChar's IPC wrapper

BUG=392724

[Dominik Röttsches, 2014-07-10 12:47:06]

Required for https://codereview.chromium.org/381893002/
more details in Behdad's explanation in the bug
https://code.google.com/p/chromium/issues/detail?id=392724

[piman, 2014-07-10 15:42:38]

On 2014/07/10 12:47:06, Dominik Röttsches wrote:
> Required for https://codereview.chromium.org/381893002/
> more details in Behdad's explanation in the bug
> https://code.google.com/p/chromium/issues/detail?id=392724

What your patch does is to distinguish between a NULL locale string and an empty
one. Is the complexity needed? I'm not sure the bug explains why...

[Dominik Röttsches, 2014-07-10 19:55:04]

On 2014/07/10 15:42:38, piman (slow to review) wrote:
> On 2014/07/10 12:47:06, Dominik Röttsches wrote:
> > Required for https://codereview.chromium.org/381893002/
> > more details in Behdad's explanation in the bug
> > https://code.google.com/p/chromium/issues/detail?id=392724
> 
> What your patch does is to distinguish between a NULL locale string and an
empty
> one. Is the complexity needed? I'm not sure the bug explains why...

The calling convention for WebFontInfo::fallbackFontForChar allows calling it
with a NULL locale string. I am mapping this convention to the IPC wrapper for
this function. We can chose to have this complexity here or check for a string
length in fallbackFontForChar and allocate an empty string on the caller side.
In my opinion, a 0 argument on the caller side more clearly expresses that we do
not want to specify a locale. In that sense, I'd prefer it this way - but I am
happy to change it if you think this change shouldn't be in the IPC layer.

[Dominik Röttsches, 2014-07-10 20:01:40]

In
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
you can see that the function is called through IPC when the sandbox is on,
otherwise directly - so it's useful if both functions, the IPC wrapper and the
direct call, have the same calling convention.

[piman, 2014-07-14 23:05:19]

On 2014/07/10 20:01:40, Dominik Röttsches wrote:
> In
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
> you can see that the function is called through IPC when the sandbox is on,
> otherwise directly - so it's useful if both functions, the IPC wrapper and the
> direct call, have the same calling convention.

I think I would prefer a simpler IPC whose structure doesn't depend on the data
- it's simpler to audit, and it's simpler to ensure that both the sender and the
receiver is using the same schema.
Actually, ideally this would use the IPC struct macros rather than pickling
everything by hand.

It's ok for the IPC wrapper to convert from a NULL string to/from an empty
string if that makes it easier.

[Dominik Röttsches, 2014-07-15 08:44:59]

On 2014/07/14 23:05:19, piman (slow to review) wrote:

> I think I would prefer a simpler IPC whose structure doesn't depend on the
data
> - it's simpler to audit, and it's simpler to ensure that both the sender and
the
> receiver is using the same schema.
> Actually, ideally this would use the IPC struct macros rather than pickling
> everything by hand.
> 
> It's ok for the IPC wrapper to convert from a NULL string to/from an empty
> string if that makes it easier.

Thanks - okay, I'll do that or I'll modify the underlying function. I actually
had used the NULL/empty conversion approach before but thought that the IPC
wrapper should not touch or alter the in/out data and changed it before
uploading.