Updated commit messages and I believe it is ready for merge.

I did split the original "-Wincompatible-pointer-types-discards-qualifiers" fix commit into two, depending on the cause of the warning (and nature of fix).

A note regarding the cast of the result of db_get_default_driver_name(). The function is defined as:

const char *db_get_default_driver_name(void)

but in fact returns a char *:

which is here then re-casted back to char *.

A note regarding the cast of the result of db_get_default_driver_name(). The function is defined as:

const char *db_get_default_driver_name(void)

but in fact returns a char *:

grass/lib/db/dbmi_base/default_name.c

Line 32 in 51fe070

return G_store(drv);

which is here then re-casted back to char *.

IMHO, db_get_default_driver_name() is correct, it provides the default driver name which should not be modified, thus const. Within the scope of this PR, I think re-casting back to char * is fine.

IMHO, db_get_default_driver_name() is correct, it provides the default driver name which should not be modified, thus const. Within the scope of this PR, I think re-casting back to char * is fine.

Oh, I do understand the logic that db_get_default_driver_name() is a const and agree it's correct. Only brought it up because I suggested the return value could be wrapped in a G_store() instead of casting, but that wouldn't make much sense in light of its implementation.

Cherry picked and pushed to master.
Thank you!

@metzm
Regarding the structure member Option->answer and the casting problems it seem to cause. I noticed that originally (at least with G5) all (string) members were char *, but this changed in 2008 (G6.4) to what we see today. Only answer (and answers) stayed mutable. The question is: do you think it's worth the effort to even explore the possibility to change ´answer´ to a const? Or will that set me off in a one-way road?