Re: [PATCH v2 1/2] Add CTYPE defines for various sets of characters.

--5NjlBkNfr6gBOT7S
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 04, 2026 at 01:50:16PM +0200, Alejandro Colomar via Mutt-dev wr=
ote:
>> From: "Kevin J. McCarthy" <[email protected]>
>>
>> Thanks to Alejandro Colomar for this suggestion, and I used his
>> examples directly for LOWER_C to PFCHAR_C.  The HEX additions are
>> mine, so you can blame those on me. ;-)
>
>:-)
>
>Actually, since there's the standard [:xdigit:] and isxdigit(3), I'd
>call it (and actually called it in shadow-utils) CTYPE_XDIGIT_C:
>
>	#define CTYPE_XDIGIT_C         CTYPE_DIGIT_C "abcdefABCDEF"

Thanks, I've renamed them to CTYPE_XDIGIT_C and CTYPE_UXDIGIT_C.

>> Please let me know what you think.  Does it help readability for the
>> cases where we use the CTYPE along with extra characters?
>> e.g. imap/command.c, lib.c, muttlib.c  below.
>
>Yup, IMO.  Where thr RFCs use a name for that, I'd give them a new name
>(see for example, CTYPE_LDH_RFC1035_C above, which corresponds to
>RFC1035's <ldh-str>), but where there's not a standard-ish name, I guess
>direct use like this is fine.
><https://www.rfc-editor.org/info/rfc1035/#section-2.3.1>

Okay.

>> diff --git a/imap/command.c b/imap/command.c
>> index 63dedf6c..94c98883 100644
>> --- a/imap/command.c
>> +++ b/imap/command.c
>> @@ -701,7 +701,7 @@ static void cmd_parse_vanished(IMAP_DATA *idata, cha=
r *s)
>>    end_of_seqset =3D s;
>>    while (*end_of_seqset)
>>    {
>> -    if (!strchr("0123456789:,", *end_of_seqset))
>> +    if (!strchr(CTYPE_DIGIT_C ":,", *end_of_seqset))
>
>I wonder if this character set has any name in RFC 7162.  I can't find
>it, though.  The only reference to DIGIT seems to be in
>mod-sequence-value.

In RFC 7162 there is:
    expunged-resp       =3D  "VANISHED" [SP "(EARLIER)"] SP known-uids
    known-uids          =3D  sequence-set
                           ;; Sequence of UIDs; "*" is not allowed.

sequence-set is in RFC 3501:
    sequence-set    =3D (seq-number / seq-range) *("," sequence-set)
    seq-range       =3D seq-number ":" seq-number
    seq-number      =3D nz-number / "*"
                -> except note the '*' is not allowed in known-uids
    nz-number       =3D digit-nz *DIGIT

So it's just a sequence of UIDs or UID ranges, each command separated,
with '*' disallowed.  Thus this addition of "," and ":".  Is this worth
making a special name for?

>> -static const char safe_chars[] =3D "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghi=
jklmnopqrstuvwxyz0123456789+@{}._-:%";
>> +static const char safe_chars[] =3D CTYPE_PFCHAR_C "+@{}:%";
>
>LGTM.  Are those extra safe chars specified by any standard, or is it
>just of this project?

Not that I can tell.  It goes way back in the commit log to 986ab5e9.

>> +#define CTYPE_PFCHAR_C       CTYPE_ALNUM_C "._-"    // POSIX.1-2008 por=
table
>> +                                                    // filename charact=
er set
>
>Actually, that was already true as of POSIX.1-2001 (Issue 6); the first
>modern-day POSIX, where POSIX and SUS (the Single UNIX Specification)
>were unified
>
>I suspect this was already true way earlier, since I see a reference to
>the 'portable filename character set' in XPG Issue 4 (v2) (from which
>modern-day POSIX derives).
><https://pubs.opengroup.org/onlinepubs/009656499/toc.pdf#page=3D423>
>I don't see the the definition of the p.f.c.s. in that document, because
>it was in a separate volume, and I can't find it.  It's also difficult
>to find older standards, unless you know where they are.  :)

Okay, I'll just leave it as "portable filename character set" in the
comment then.

>LGTM.

Great.  Thanks Alex!

--=20
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA

--5NjlBkNfr6gBOT7S
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEiXWpszqjeRA4XFMIre92hIAxa9oFAmpysAoACgkQre92hIAx
a9rGJw/+Lb7d4MXqgw5zZ+x2er4KNDODECpB+/SDM/tB+49aYbYC4AlVTOPVaUHo
wrHmmDzCHZusDkrs5EawIsXhjI6c4TTvDx+X64jnVngEDs8burEuyocMm0wzk7U9
J4djX+CUCTv7s6VkGPAsD647gPwsaPwfNOHHDZqw9YZCcFl3IgGkXSpS7S9kTEwV
IAFsgTj6mvCiDhaeXbGN7eYjUB2jOCadmu6/03oI4luHMRPgLs/Xou7pHX2wXfKv
afzFYppRipqKEhz9YSsPROcfLruUpAjlOlMYHHnLNJykUzeI+NMM0+tYQ+m7oFEX
jRQnRCHWeVv1zpmmba5d2DZMUtiXWY0z0rkvLRcQPZ55iGflfqkwPiGJWSFqGrlh
yV4ZOAz1dmIU3FlyaPRlCvokGGvRUZdnJdQVrcHoQ98W8en7dbR6gZBdZ2iexORq
+GKmtpCP9s2LcL1iFprssmXu1WSS1IQ7cX6s5n6Za1GwXx4qzSD/egfB3X0ukt6R
CZU1Kg7VTi0/onIpmy+IAlIHbp42ZoT2XdQefxqJVuyl3dCHWyLcbOqZ44d8iPlY
LbNIwupNWeWucOH7mdtZ+h/xvGI+bawZWOYlmYVulRu0Q1GGeif2voPhDO2Z3pw4
HoY5XLYTps3QLZEspsflcF87OXagA0eHia4bN2sE3kbcoBPRAI4=
=8BU+
-----END PGP SIGNATURE-----

--5NjlBkNfr6gBOT7S--