avoid out-of-bound access in mystrncpy()

[giallu]

the mystrncpy() function as is written now:

InChI/INCHI-1-SRC/INCHI_BASE/src/util.c

Lines 1712 to 1740 in c3eed49

	int mystrncpy(char *target, const char *source, unsigned maxlen)
	{
	const char *p;
	unsigned len;
	if (target == NULL || maxlen == 0 || source == NULL)
	{
	return 0;
	}
	if ((p = (const char*)memchr(source, 0, maxlen))) /* djb-rwth: addressing LLVM warning */
	{ /* maxlen does not include the found zero termination */
	len = (int) (p - source);
	}
	else
	{ /* reduced length does not include one more byte for zero termination */
	len = maxlen - 1;
	}
	if (len)
	{
	memmove(target, source, len);
	}
	memset(target + len, 0, maxlen - len);
	/* zero termination */ /* djb-rwth: memset_s C11/Annex K variant? */
	return 1;
	}

will read past the end of the source string when used like this:

InChI/INCHI-1-SRC/INCHI_API/libinchi/src/inchi_dll.c

Line 1570 in c3eed49

mystrncpy( at[a1].elname, "H", sizeof( at->elname ) );

for this reason, I propose checking first if the source string is shorter than maxlen, and act appropriately

by the way, trying to be smarter than the standard library is rarely a good idea, I'd see if it's possible to just use strncpy or at leasemake mystrncpy a wrapper around it.

[djb-rwth]

Hi @giallu,
Thanks for creating this PR.
The proposed fix should work.
This looks like a custom-made version of strncpy made by a previous developer with intention to overcome issues with zero termination.

It might be worth considering if target has been allocated with enough memory, but that would lead to writing custom boundary check function which would emulate strncpy_s; however, I definitely would not go that far.