use of uninitialized values in mo_cdi::vlistInqVarName
In a valgrind run, I get
==3339454== Conditional jump or move depends on uninitialised value(s)
==3339454== at 0xDBD7AC9: string_len_trim (string_intrinsics_inc.c:240)
==3339454== by 0xDBD7AC9: _gfortran_string_len_trim (string_intrinsics_inc.c:186)
==3339454== by 0x24918DE: __mo_cdi_MOD_vlistinqvarname (mo_cdi.f90:4179)
==3339454== by 0x84CE59: __mo_util_cdi_MOD_makeinputparameters (mo_util_cdi.f90:191)
==3339454== by 0x6B8663: __mo_ext_data_init_MOD_read_ext_data_atm.constprop.0 (mo_ext_data_init.f90:1203)
==3339454== by 0x6BD2B5: __mo_ext_data_init_MOD_init_ext_data (mo_ext_data_init.f90:350)
==3339454== by 0x442A8A: __mo_atmo_model_MOD_construct_atmo_model (mo_atmo_model.f90:579)
==3339454== by 0x44451D: __mo_atmo_model_MOD_atmo_model (mo_atmo_model.f90:186)
==3339454== by 0x40E4B6: MAIN__ (icon.f90:227)
==3339454== by 0x40D78C: main (icon.f90:30)
==3339454==
The line referenced, if(name_dummy(name_i:name_i) /= ' ') exit
, doesn't call LEN_TRIM
. But it might be that gfortran is very smart optimizing the enclosing DO to the equivalent name_temp(len_trim(name_dummy)+1:) = c_null_char
. Anyway, in this context vlistInqVarName
is called with an uninitialized name_dummy
. This is correct, I believe, because the name should be an output of the function.
Digging deeper, it seems like the value of name_temp
isn't read at all. The copy-in is unnecessary. There is another problem, though: the C function vlistInqVarName
claims that the maximum length of the buffer it passes into cdiInqKeyString
is CDI_MAX_NAME
(=256). On the Fortran side the length of the buffer is len(name_dummy) + 1
, which might be shorter and cause memory corruption. In this context name_dummy
has a length of 1024, so it isn't an issue here.
My suggestion is to remove the copy-in part, declare name_temp
with a fixed length CDI_MAX_NAME
, and copy-out the first len(name_dummy)
characters (this is already implemented correctly).