lib/gis: Add portable G_strlcpy function

[lbartoletti]

From commit message:

This commit introduces a new G_strlcpy function in lib/gis, inspired by
G_asprintf. G_strlcpy provides a safer alternative to strcpy and strncpy,
with consistent behavior across different systems.

Key points:

• Implements strlcpy functionality, available natively on BSD systems
• Portable implementation for non-BSD systems (excluding Linux with libbsd)
• Based on FreeBSD's implementation:
  https://github.com/freebsd/freebsd-src/blob/98dd639c94f716858ae29958f484729b1d2fd387/sys/libkern/strlcpy.c#L28
• Designed to replace unsafe uses of strcpy and strncpy throughout the project

The function is implemented to use the native strlcpy where available,
falling back to our portable version on systems without it. This ensures
optimal performance on BSD systems while maintaining compatibility across
different platforms.

By providing G_strlcpy, we aim to improve the overall safety and
consistency of string operations in our codebase.

Marked as draft for now, since only tested on FreeBSD, which have strlcpy of course 😉

Supersed #4087 for the "test"

[lbartoletti]

@ShubhamDesai @echoix everywhere a strcpy is replaced by a strncpy + null termination, you could use the BSD (non-portable) strlcpy function.

https://man.freebsd.org/cgi/man.cgi?strlcpy(3)

[lbartoletti]

checking for strlcpy... no for Ubuntu and yes for macOS (BSD-like) as expected. And r.path builds, nice!

[nilason]

I think this is a great addition, after just reading the code I have some suggestions.

[echoix]

How does windows support look like? (Passing CI doesn't mean anything for now)

[nilason]

restrict doesn't work well with C++, we can try remove it completely from the gis.h file only, but keep it in strlcpy.c. If that doesn't work it may be removed altogether.

[lbartoletti]

restrict doesn't work well with C++, we can try remove it completely from the gis.h file only, but keep it in strlcpy.c. If that doesn't work it may be removed altogether.

restrict is on FreeBSD version, but not used on other version, for example, the original OpenBSD https://github.com/libressl/openbsd/blob/master/src/lib/libc/string/strlcpy.c#L28

[lbartoletti]

How does windows support look like? (Passing CI doesn't mean anything for now)

Like for Linux, Windows doesn't have strlcpy and will use "our" function. And, it's ok, also on Windows, since it's use only C standard function.

[nilason]

restrict doesn't work well with C++, we can try remove it completely from the gis.h file only, but keep it in strlcpy.c. If that doesn't work it may be removed altogether.

restrict is on FreeBSD version, but not used on other version, for example, the original OpenBSD https://github.com/libressl/openbsd/blob/master/src/lib/libc/string/strlcpy.c#L28

Yes, it is not required, but a compiler optimisation which we now can use (since we are supporting C11 standard). I don't think it is necessary to declare it in the prototype (gis.h).

[lbartoletti]

restrict doesn't work well with C++, we can try remove it completely from the gis.h file only, but keep it in strlcpy.c. If that doesn't work it may be removed altogether.

restrict is on FreeBSD version, but not used on other version, for example, the original OpenBSD https://github.com/libressl/openbsd/blob/master/src/lib/libc/string/strlcpy.c#L28

Yes, it is not required, but a compiler optimisation which we now can use (since we are supporting C11 standard). I don't think it is necessary to declare it in the prototype (gis.h).

In fact, I think, __restrict is better for C/C++ https://learn.microsoft.com/fr-fr/cpp/cpp/extension-restrict?view=msvc-170 (and other like wikipedia etc)

[nilason]

restrict doesn't work well with C++, we can try remove it completely from the gis.h file only, but keep it in strlcpy.c. If that doesn't work it may be removed altogether.

restrict is on FreeBSD version, but not used on other version, for example, the original OpenBSD https://github.com/libressl/openbsd/blob/master/src/lib/libc/string/strlcpy.c#L28

Yes, it is not required, but a compiler optimisation which we now can use (since we are supporting C11 standard). I don't think it is necessary to declare it in the prototype (gis.h).

In fact, I think, __restrict is better for C/C++ https://learn.microsoft.com/fr-fr/cpp/cpp/extension-restrict?view=msvc-170 (and other like wikipedia etc)

__restrict/__restrict__ etc are compiler specific, and may or may not work. We'd better keep us to the standard.

[nilason]

restrict doesn't work well with C++, we can try remove it completely from the gis.h file only, but keep it in strlcpy.c. If that doesn't work it may be removed altogether.

restrict is on FreeBSD version, but not used on other version, for example, the original OpenBSD https://github.com/libressl/openbsd/blob/master/src/lib/libc/string/strlcpy.c#L28

Yes, it is not required, but a compiler optimisation which we now can use (since we are supporting C11 standard). I don't think it is necessary to declare it in the prototype (gis.h).

In fact, I think, __restrict is better for C/C++ https://learn.microsoft.com/fr-fr/cpp/cpp/extension-restrict?view=msvc-170 (and other like wikipedia etc)

__restrict/__restrict__ etc are compiler specific, and may or may not work. We'd better keep us to the standard.

An alternative way, could possibly be to use:

extern "C"
{
  #include "grass/gis.h"
}

in all C++ files. Like:

grass/imagery/i.atcorr/main.cpp

Lines 41 to 46 in 0645510

	extern "C" {
	#include <grass/gis.h>
	#include <grass/raster.h>
	#include <grass/glocale.h>
	#include <grass/rbtree.h>
	}

Or add a:

#ifdef __cplusplus
extern "C"
{
#endif

// original content of gis.h

#ifdef __cplusplus
}
#endif

then we can probably use restrict in gis.h as well (which would be preferable for clarity).

The former (the extern "C" version for cpp files), if this solves the problem with the restrict keyword, is probably the better solution anyway.

[nilason]

With the following suggested changes also C++ file can include gis.h. 'export "C"' doesn't to the trick.

(Historically, prototypes in GRASS doesn't have named parameters.)

[lbartoletti]

With the following suggested changes also C++ file can include gis.h. 'export "C"' doesn't to the trick.

(Historically, prototypes in GRASS doesn't have named parameters.)

Nice, thanks!

[nilason]

I'm ready to merge this if there are no objections.

I have a very minor stylistic suggestion below. And since we have a squash-and-merge policy, I would prefer if you'd remove the r.path changes, to keep clean commits (it may be addressed with #4087).

[lbartoletti]

I'm ready to merge this if there are no objections.

I have a very minor stylistic suggestion below. And since we have a squash-and-merge policy, I would prefer if you'd remove the r.path changes, to keep clean commits (it may be addressed with #4087).

Thanks. I removed the r.path changes

[nilason]

@lbartoletti Thanks!!