Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PING][PATCH] [gdb] Improve selftest c_ctrl_unctrl
Date: Fri, 10 Apr 2026 14:32:10 +0200	[thread overview]
Message-ID: <790738dd-c257-4cc7-870c-8bb7b08ed1ef@suse.de> (raw)
In-Reply-To: <20260326140401.4160862-1-tdevries@suse.de>

On 3/26/26 3:04 PM, Tom de Vries wrote:
> Improve selftest c_ctrl_unctrl by exercising all valid inputs of c_iscntrl.
> 

Ping.

Thanks,
- Tom

> Tested on x86_64-linux.
> 
> Suggested-By: Tom Tromey <tom@tromey.com> [1]
> 
> [1] https://sourceware.org/pipermail/gdb-patches/2026-March/226231.html
> ---
>   gdb/utils.c | 24 +++++++++++++++++++++---
>   1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/gdb/utils.c b/gdb/utils.c
> index b073bb9fdf3..c8903896081 100644
> --- a/gdb/utils.c
> +++ b/gdb/utils.c
> @@ -3793,12 +3793,30 @@ test_c_ctrl_unctrl ()
>     SELF_CHECK (c_ctrl ('?') == 0x7f);
>     SELF_CHECK (c_unctrl (0x7f) == '?');
>   
> -  /* Consistency check.  */
> -  for (unsigned int i = 0; i < 0x100; i++)
> +  /* Consistency check.
> +
> +     The ctype.h function iscntrl has an int parameter, and defined behavior
> +     for inputs [0, 255] and EOF.  Consequently, iscntrl has undefined
> +     behavior when called with a negative signed char argument (with the
> +     possible exception of EOF, which is a negative int constant).  That
> +     extends to chars on platforms where char == signed char.  Consequently,
> +     to write portable code, iscntrl char and signed char arguments need to be
> +     cast to unsigned char.
> +
> +     The c-ctype.h variant c_iscntrl sidesteps this problem by having defined
> +     behavior for inputs [-128, 255] and not bothering about EOF.
> +
> +     The functions c_ctrl/c_unctrl sidestep this issue by using parameter
> +     type unsigned char instead of int.
> +
> +     So, testing input values [0..255] tests all relevant behavior of
> +     c_ctrl/c_unctrl.  However, we designed these functions to be compatible
> +     with c_iscntrl, so we test for all valid inputs of that function.  */
> +  for (int i = -128; i < 256; i++)
>       {
>         unsigned char ch = i;
>         unsigned char unctrl_ch = c_unctrl (ch);
> -      if (!c_iscntrl (ch))
> +      if (!c_iscntrl (i))
>   	{
>   	  SELF_CHECK (unctrl_ch == ch);
>   	  continue;
> 
> base-commit: edf0ae3b9f1ca23daaa55628683edc9a3360286f


  reply	other threads:[~2026-04-10 12:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-26 14:04 [PATCH] " Tom de Vries
2026-04-10 12:32 ` Tom de Vries [this message]
2026-04-24 13:16   ` [PING][PATCH] " Tom de Vries

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=790738dd-c257-4cc7-870c-8bb7b08ed1ef@suse.de \
    --to=tdevries@suse.de \
    --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