Fix a (one shot small) leak in language.c

Valgrind detects the following leak:
==28395== VALGRIND_GDB_ERROR_BEGIN
==28395== 5 bytes in 1 blocks are definitely lost in loss record 20 of 2,770
==28395==    at 0x4C2BE2D: malloc (vg_replace_malloc.c:299)
==28395==    by 0x41D9E7: xmalloc (common-utils.c:44)
==28395==    by 0x78BF39: xstrdup (xstrdup.c:34)
==28395==    by 0x51F1AC: _initialize_language() (language.c:1175)
==28395==    by 0x6B3356: initialize_all_files() (init.c:308)
==28395==    by 0x66D194: gdb_init(char*) (top.c:2159)
==28395==    by 0x554C11: captured_main_1 (main.c:863)
==28395==    by 0x554C11: captured_main (main.c:1167)
==28395==    by 0x554C11: gdb_main(captured_main_args*) (main.c:1193)
==28395==    by 0x29D837: main (gdb.c:32)
==28395==
==28395== VALGRIND_GDB_ERROR_END

This is a very small leak (1 block/5 bytes), happening only once
per GDB startup as far as I can see. But this fix make the nr of leaking
GDB in the testsuite decreasing from 628 to 566.

It is unclear why a xstrdup-ed value is assigned to 'language'
at initialization time, while a static "auto" string is assigned
as part of the set_language_command.
So, that shows that it is ok to initialize 'language' directly
with "auto".
Also, I cannot find any place where 'language' is xfree-d.
No leak was detected for 'range' and 'case_sensitive', but
similarly, no indication why a static string cannot be assigned.

Regression-tested on debian/x86_64.
Also, full testsuite run under valgrind, less tests leaking,
and no dangling pointer problem detected.

gdb/ChangeLog
2018-12-05  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* language.c (_initialize_language): Fix leak by assigning
	a static string to language.  Same for range and case_sensitive,
	even if no leak is detected for these variables.

0 files changed, 0 insertions, 0 deletions