Re: widl: Initialize variables that are not necessarily filled in encode_type
On Mon, Feb 20, 2017 at 10:06:46PM +0100, André Hentschel wrote:
Signed-off-by: André Hentschel <nerv(a)dawncrow.de> ---
This helps with reproducable builds
tools/widl/write_msft.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c index 137bb2d..39be30b 100644 --- a/tools/widl/write_msft.c +++ b/tools/widl/write_msft.c @@ -2195,7 +2195,7 @@ static void add_union_typeinfo(msft_typelib_t *typelib, type_t *tunion) static void add_typedef_typeinfo(msft_typelib_t *typelib, type_t *tdef) { msft_typeinfo_t *msft_typeinfo = NULL; - int alignment, datatype1, datatype2, size, duplicate = 0; + int alignment = 0, datatype1 = 0, datatype2 = 0, size = 0, duplicate = 0;
encode_type() initializes alignment, datatype1 and size in all cases, so these are unnecessary. The question then becomes where is the best place to initialize datatype2 (a.k.a. decoded_size). Since no caller to encode_type() relies on the existing value being preserved, it makes sense to initialize it in encode_type(). So just send the patch you originally sent to wine-devel. Huw.
Am 22.02.2017 um 10:35 schrieb Huw Davies:
On Mon, Feb 20, 2017 at 10:06:46PM +0100, André Hentschel wrote:
Signed-off-by: André Hentschel <nerv(a)dawncrow.de> ---
This helps with reproducable builds
tools/widl/write_msft.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c index 137bb2d..39be30b 100644 --- a/tools/widl/write_msft.c +++ b/tools/widl/write_msft.c @@ -2195,7 +2195,7 @@ static void add_union_typeinfo(msft_typelib_t *typelib, type_t *tunion) static void add_typedef_typeinfo(msft_typelib_t *typelib, type_t *tdef) { msft_typeinfo_t *msft_typeinfo = NULL; - int alignment, datatype1, datatype2, size, duplicate = 0; + int alignment = 0, datatype1 = 0, datatype2 = 0, size = 0, duplicate = 0;
encode_type() initializes alignment, datatype1 and size in all cases, so these are unnecessary. The question then becomes where is the best place to initialize datatype2 (a.k.a. decoded_size). Since no caller to encode_type() relies on the existing value being preserved, it makes sense to initialize it in encode_type(). So just send the patch you originally sent to wine-devel.
Huw.
as far as I can see those variables are also not set in every case, e.g. VT_VARIANT further the encode_type() can recurse, and I would expect the variables to stay the same (in case they need to be incremented), so setting decoded_size to 0 at the beginning seems wrong on the other hand, no incrementation is done, so I think for now I can resend my old patch... I just wonder what to do with the other variables
On Wed, Feb 22, 2017 at 07:59:50PM +0100, André Hentschel wrote:
Am 22.02.2017 um 10:35 schrieb Huw Davies:
On Mon, Feb 20, 2017 at 10:06:46PM +0100, André Hentschel wrote:
Signed-off-by: André Hentschel <nerv(a)dawncrow.de> ---
This helps with reproducable builds
tools/widl/write_msft.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/widl/write_msft.c b/tools/widl/write_msft.c index 137bb2d..39be30b 100644 --- a/tools/widl/write_msft.c +++ b/tools/widl/write_msft.c @@ -2195,7 +2195,7 @@ static void add_union_typeinfo(msft_typelib_t *typelib, type_t *tunion) static void add_typedef_typeinfo(msft_typelib_t *typelib, type_t *tdef) { msft_typeinfo_t *msft_typeinfo = NULL; - int alignment, datatype1, datatype2, size, duplicate = 0; + int alignment = 0, datatype1 = 0, datatype2 = 0, size = 0, duplicate = 0;
encode_type() initializes alignment, datatype1 and size in all cases, so these are unnecessary. The question then becomes where is the best place to initialize datatype2 (a.k.a. decoded_size). Since no caller to encode_type() relies on the existing value being preserved, it makes sense to initialize it in encode_type(). So just send the patch you originally sent to wine-devel.
Huw.
as far as I can see those variables are also not set in every case, e.g. VT_VARIANT further the encode_type() can recurse, and I would expect the variables to stay the same (in case they need to be incremented), so setting decoded_size to 0 at the beginning seems wrong on the other hand, no incrementation is done, so I think for now I can resend my old patch... I just wonder what to do with the other variables
The VT_VARIANT case is a bug, I'll work on fixing that, thanks for spotting it. The recursion is handled by passing a separate variable and adding it after return. I suspect that the cumulative approach was originally the plan, and that's why *decoded_size was never initialized. Huw.
participants (2)
-
André Hentschel -
Huw Davies