From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: Re: [PING][PATCH] [gdb] Improve selftest c_ctrl_unctrl
Date: Fri, 24 Apr 2026 15:16:16 +0200 [thread overview]
Message-ID: <4c68fd57-f26c-429d-900e-6faa0d48d432@suse.de> (raw)
In-Reply-To: <790738dd-c257-4cc7-870c-8bb7b08ed1ef@suse.de>
On 4/10/26 2:32 PM, Tom de Vries wrote:
> 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.
>
I've pushed this.
Thanks,
- Tom
> 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
>
prev parent reply other threads:[~2026-04-24 13:16 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 ` [PING][PATCH] " Tom de Vries
2026-04-24 13:16 ` Tom de Vries [this message]
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=4c68fd57-f26c-429d-900e-6faa0d48d432@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