lib/db: Fix copy into fixed size buffer issue in SQLite driver

[ShubhamDesai]

This pull request resolves a buffer overflow issue detected by Coverity Scan (CID 1501211).
strcpy is replaced with G_strlcpy

[nilason]

As I mentioned, in this case the G_strlcpy() and check nicely fits in one line, so no need to use a variable (len).

I'm not sure whether this should result in warning or error, the result is in this case truncated. @wenzeslaus or @neteler what do you say?

[echoix]

As I mentioned, in this case the G_strlcpy() and check nicely fits in one line, so no need to use a variable (len).

I'm not sure whether this should result in warning or error, the result is in this case truncated. @wenzeslaus or @neteler what do you say?

I'm going to try a take on this.

Considering that this is library code, I would expect it to be more robust than a module or addon;
Considering also that it is for doing database (SQLite?), where database operations are expected to be fully completed as requested or not at all, (see ACID concepts);
Considering that using a warning when operations would end up truncating a database name, and continuing the execution to another database, not the intended one (for example a database file that matches the name of the truncated string on warning);
I think that if the preconditions aren't met, we should fail. We aren't supposed to be in situations where we are in buffer-overflow territory, but when we are, we might as well limit the damages and stopping soon.

Would that approach make sense? Is there a completely different point of view that I didn't consider?

[nilason]

We should probably issue warning and return DB_FAILED, but I need to take a closer look at this.

[nilason]

The database library has its own set of functions handling errors. A more proper way to handle these failures is illustrated by:

grass/db/drivers/sqlite/db.c

Lines 123 to 126 in adcdf28

	db_d_append_error("%s %s\n%s", _("Unable to open database:"), name3,
	(char *)sqlite3_errmsg(sqlite));
	db_d_report_error();
	return DB_FAILED;

The modules are (relatively) short lived and if there is a failure it may exit the process with e.g. G_fatal_error. A caller to the library, on the other hand, may wish to do some cleaning up or make an alternative approach in case of failure.