Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@efficios.com>
To: Andrew Burgess <aburgess@redhat.com>,
	gdb-patches@sourceware.org, binutils@sourceware.org
Subject: Re: [PATCH 10/13] gdbsupport: add xstrcpy
Date: Mon, 17 Aug 2026 13:30:44 -0400	[thread overview]
Message-ID: <81ece47e-5901-49db-b468-89e0b247367f@efficios.com> (raw)
In-Reply-To: <87bjb03dc5.fsf@redhat.com>

On 8/17/26 12:45 PM, Andrew Burgess wrote:
> Simon Marchi <simon.marchi@efficios.com> writes:
> 
>> Add xstrcpy, a "safe" alternative to strcpy.  It works like strcpy, but
>> accepts the size of the destination buffer, and asserts that the string
>> fits in it.
>>
>> Return the number of characters copied, so that it's possible to easily
>> chain calls like this:
>>
>>   p += xstrcpy (p, end - p, ",C");
> 
> Don't functions that take a buffer size usually include an 'n' in the
> name.  That seems to be true for libc, but also throughout GDB.  Would
> it not be a good idea to adopt that here too.
> 
> This isn't exactly strncpy, but it seems similar.  While strncpy can
> result in a non-null terminated output string, this "xstrncpy" asserts
> that the source fits into the output buffer without being truncated.
> But otherwise, it's the same function I think?

I hesitated about naming it strncpy.  I decided against it because the
new function doesn't behave exactly like strcnpy on one specific point:
if the source is smaller than destination, strncpy fills the remainder
of the destination buffer with zeroes.  Not sure if that matters in
practice, but it could be the source of a subtle bug if one blindly
switches strncpy for xstrncpy.

Both strcpy and strncpy return a pointer to the beginning of the
destination buffer, which is different than my xstrcpy, which returns
the number of bytes written.  The latter seems more useful to me, as
it makes it possible to easily chain the calls.

It seems like xstrcpy is more like a wrapper for strlcpy, so we could
always call it xstrlcpy.  The only thing is that the argument order is
not the same:

  int    xstrcpy (char *dst, size_t size, const char *src);
  size_t strlcpy (char *dst, const char *src, size_t size);

So if we named it xstrlcpy, I would want to match xstrlcpy's argument
order, otherwise it's just confusing.  Personally, I don't strlcpy's
argument order as much, because `size` describes `dst`, so I like having
it right next to it.  But I could live with it.

I just noticed that strcpy_s exists in C11, and it is in the same order
as xstrcpy:

  errno_t strcpy_s (char* restrict dest, rsize_t destsz, const char* restrict src);

It looks like we could use that, but we also want to return the number
of bytes written, which this does not provide.

I also considered accepting `dst` as a `gdb::array_view<char>`, which
would side-step the argument order problem, but the caller's are not
really ready for that, so their would look look awkward.

In any case, I still believe that the xstrcpy makes sense, because it is
really like "strcpy, but safe".

Given all this, what would be your choice?

Simon

  reply	other threads:[~2026-08-17 17:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17 15:16 [PATCH 00/13] Fix various warnings when building on macOS Simon Marchi
2026-08-17 15:16 ` [PATCH 01/13] gdbsupport: remove uses of vsprintf Simon Marchi
2026-08-17 15:47   ` Andrew Burgess
2026-08-17 15:16 ` [PATCH 02/13] gdbsupport: remove uses of sprintf Simon Marchi
2026-08-17 15:49   ` Andrew Burgess
2026-08-17 15:16 ` [PATCH 03/13] opcodes/z80: remove use " Simon Marchi
2026-08-18  6:40   ` Jan Beulich
2026-08-18 16:48     ` Simon Marchi
2026-08-17 15:16 ` [PATCH 04/13] sim/ppc: make defines.h sed command portable Simon Marchi
2026-08-17 15:36   ` Andrew Burgess
2026-08-17 15:16 ` [PATCH 05/13] sim/m32r: fix unused variable warning on non-Linux hosts Simon Marchi
2026-08-17 15:36   ` Andrew Burgess
2026-08-17 15:16 ` [PATCH 06/13] sim/m32r: fix unused function warnings " Simon Marchi
2026-08-17 15:37   ` Andrew Burgess
2026-08-17 15:16 ` [PATCH 07/13] gdb/csky: remove uses of sprintf Simon Marchi
2026-08-17 16:26   ` Andrew Burgess
2026-08-17 17:03     ` Simon Marchi
2026-08-17 20:50     ` Tom Tromey
2026-08-18 18:26       ` Simon Marchi
2026-08-17 15:16 ` [PATCH 08/13] gdb/dwarf2: " Simon Marchi
2026-08-17 16:35   ` Andrew Burgess
2026-08-17 15:16 ` [PATCH 09/13] gdb/elfread: remove use " Simon Marchi
2026-08-17 16:38   ` Andrew Burgess
2026-08-17 15:16 ` [PATCH 10/13] gdbsupport: add xstrcpy Simon Marchi
2026-08-17 16:45   ` Andrew Burgess
2026-08-17 17:30     ` Simon Marchi [this message]
2026-08-17 15:16 ` [PATCH 11/13] gdb/remote-fileio: remove uses of sprintf Simon Marchi
2026-08-17 16:53   ` Andrew Burgess
2026-08-17 15:16 ` [PATCH 12/13] gdb/remote: " Simon Marchi
2026-08-17 16:51   ` Andrew Burgess
2026-08-17 17:34     ` Simon Marchi
2026-08-17 15:16 ` [PATCH 13/13] gdb/tracepoint: " Simon Marchi
2026-08-17 16:51   ` Andrew Burgess
2026-08-17 20:52 ` [PATCH 00/13] Fix various warnings when building on macOS Tom Tromey
2026-08-18 18:10 ` Simon Marchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81ece47e-5901-49db-b468-89e0b247367f@efficios.com \
    --to=simon.marchi@efficios.com \
    --cc=aburgess@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox