Update externs in unicodenormalization.cpp to not have array sizes.

Update externs in unicodenormalization.cpp to not have array sizes.

This is a follow-up to f9640495.

R=brucedawson@chromium.org

Committed: https://pdfium.googlesource.com/pdfium/+/dd132d8d1e9a27673e5357a657db2b97dda9bcdb

[Lei Zhang, 2015-01-05 23:11:20]

thestig@chromium.org changed reviewers:
+ brucedawson@chromium.org

[brucedawson, 2015-01-05 23:13:24]

https://codereview.chromium.org/825983004/diff/1/core/src/fpdftext/unicodenor...
File core/src/fpdftext/unicodenormalizationdata.cpp (left):

https://codereview.chromium.org/825983004/diff/1/core/src/fpdftext/unicodenor...
core/src/fpdftext/unicodenormalizationdata.cpp:8: extern const FX_WCHAR
g_UnicodeData_Normalization[65536] = {
Does removing this actually work? 'const' implies static so without the extern I
would expect linker errors because the other source file would no longer be able
to see the arrays.

[Lei Zhang, 2015-01-05 23:22:32]

On 2015/01/05 23:13:24, brucedawson wrote:
>
https://codereview.chromium.org/825983004/diff/1/core/src/fpdftext/unicodenor...
> File core/src/fpdftext/unicodenormalizationdata.cpp (left):
> 
>
https://codereview.chromium.org/825983004/diff/1/core/src/fpdftext/unicodenor...
> core/src/fpdftext/unicodenormalizationdata.cpp:8: extern const FX_WCHAR
> g_UnicodeData_Normalization[65536] = {
> Does removing this actually work? 'const' implies static so without the extern
I
> would expect linker errors because the other source file would no longer be
able
> to see the arrays.

Nope, doesn't work. Since the pdf target is a shared library, symbols can be
undefined so the linking doesn't fail. It fails at runtime instead. See patch
set 2.

[brucedawson, 2015-01-05 23:26:55]

Ah -- Linux shared objects always surprise me with that behavior. On Windows it
would be a linker failure.

Anyway, with that changed, lgtm.

[Lei Zhang, 2015-01-05 23:27:41]

Committed patchset #2 (id:20001) manually as
dd132d8d1e9a27673e5357a657db2b97dda9bcdb (presubmit successful).