Fix uninitialized font_offset

Fix uninitialized font_offset

BUG=387840
R=palmer@chromium.org

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

[palmer, 2014-07-07 19:32:31]

lgtm

[jun_fang, 2014-07-07 20:42:50]

Committed patchset #2 manually as rcceb554 (presubmit successful).

[mdoppler, 2014-07-11 10:45:50]

On 2014/07/07 20:42:50, jun_fang wrote:
> Committed patchset #2 manually as rcceb554 (presubmit successful).

This breaks building with the VS 2010 Microsoft Compiler because variable
assignments are required to be done after variable declarations /
initializations in plain C.

Compile error:

.\core\src\fxge\fx_freetype\fxft2.5.01\src\type1\t1gload.c(287) : error C2275:
'FT_Data' : illegal use of this type as an expression
...

This can be fixed by moving the two assignments after the declarations:

diff --git a/core/src/fxge/fx_freetype/fxft2.5.01/src/type1/t1gload.c
b/core/src/fxge/fx_freetype/fxft2.5.01/src/type1/t1gload.c
index d06e161..237e535 100644
--- a/core/src/fxge/fx_freetype/fxft2.5.01/src/type1/t1gload.c
+++ b/core/src/fxge/fx_freetype/fxft2.5.01/src/type1/t1gload.c
@@ -282,13 +282,13 @@
 
     FT_Matrix               font_matrix;
     FT_Vector               font_offset;
-    font_offset.x           = 0;
-    font_offset.y           = 0;
     FT_Data                 glyph_data;
     FT_Bool                 must_finish_decoder = FALSE;
 #ifdef FT_CONFIG_OPTION_INCREMENTAL
     FT_Bool                 glyph_data_loaded = 0;
 #endif
+    font_offset.x           = 0;
+    font_offset.y           = 0;
 
 
 #ifdef FT_CONFIG_OPTION_INCREMENTAL

[palmer, 2014-07-11 17:11:27]

> This breaks building with the VS 2010 Microsoft Compiler because variable
> assignments are required to be done after variable declarations /
> initializations in plain C.

Sorry, we don't intend to support build environments that old. The breakage is
likely to get worse over time, I'm afraid.

[mdoppler, 2014-07-17 06:34:53]

Someone else opened an issue for this problem as well:

https://code.google.com/p/pdfium/issues/detail?id=23

I understand that you don't want to put much effort into VS 2010, but compliance
of this compiler is pretty good (for a ms compiler), so i would not expect much
further breakage in the future.