Re: [PATCH] gdb: replace alloca with gdb::char_vector in remote-fileio.c

[Pedro Alves <pedro@palves.net>]

On 2026-06-30 10:52, Luis Machado wrote:

>  static int
> -remote_fileio_extract_ptr_w_len (char **buf, CORE_ADDR *ptrval, int *length)
> +remote_fileio_extract_ptr_w_len (char **buf, CORE_ADDR *ptrval, int *length,
> +				  bool allow_zero_length = false)
>  {
>    char *c;
>    LONGEST retlong;
> @@ -211,6 +215,11 @@ remote_fileio_extract_ptr_w_len (char **buf, CORE_ADDR *ptrval, int *length)
>    *buf = c;
>    if (remote_fileio_extract_long (buf, &retlong))
>      return -1;
> +  /* Reject negative lengths, zero (unless the caller permits it for the
> +     Fsystem NULL-cmdline sentinel), and lengths above PATH_MAX to prevent
> +     out-of-bounds memory reads or oversized heap allocations.  */
> +  if (retlong < 0 || (!allow_zero_length && retlong == 0) || retlong > PATH_MAX)
> +    return -1;


PATH_MAX is NOT guaranteed to exist.  It's a portability hazard.  Note how the only place in
common code that uses it, in inf-child.c, has "#if defined (PATH_MAX)" guarding it.
The uses in remote-fileio.c itself are guarded by __CYGWIN__.

POSIX allows PATH_MAX to be undefined when the limit is indeterminate.  GNU/Hurd is the canonical case,
it has no PATH_MAX at all.

On Windows, there's MAX_PATH (not a typo, it's really the reserve word order of PATH_MAX), defined as 260,
though syscalls allow more than that.  gnulib's import/pathmax.h does give us PATH_MAX on Windows (but not
on Hurd, see comments there), but also defined as 260.

On macOS PATH_MAX is 1024, but some syscalls accept longer.

Etc.

The GNU conventions is just to not code a limit, and use dynamic allocation.  The patch already switches
from alloca to the heap, so we can just drop the PATH_MAX cap.  The buffers are transient and
passed to open, stat etc. syscalls immediately, and release immediately.  The syscalls fail with ENAMETOOLONG
if truly passed a too-long name, so the cap adds zero safety.


>    *length = (int) retlong;
>    return 0;
>  }
> @@ -305,7 +314,6 @@ remote_fileio_func_open (remote_target *remote, char *buf)
>    long num;
>    int flags, fd;
>    mode_t mode;
> -  char *pathname;
>    struct stat st;
>  
>    /* 1. Parameter: Ptr to pathname / length incl. trailing zero.  */
> @@ -339,8 +347,8 @@ remote_fileio_func_open (remote_target *remote, char *buf)
>      }
>  
>    /* Request pathname.  */
> -  pathname = (char *) alloca (length);
> -  if (target_read_memory (ptrval, (gdb_byte *) pathname, length) != 0)
> +  gdb::char_vector pathname (length);

"pathname" never needs to be resized, so std::vector adds a bit of useless weight (it needs to
track storage vs size separately, etc.).  Make it a gdb::unique_xmalloc_ptr<char> instead.
That's the only change needed, all the rest of the code will work the same.

(Ditto for all the other instances.  You do have one resize call further below, but that's
not a real resize, it's still just initialization.)