From: Andrew Zaborowski <andrew.zaborowski@intel.com>
To: ell@lists.01.org
Subject: Re: ctype.h undefined behaviour on signed char platforms, needs cast to (unsigned char)
Date: Sun, 22 Nov 2020 00:18:13 +0100 [thread overview]
Message-ID: <CAOq732+x4g5-D=vXJNTgC=TT-Y4Y6axmoXWbMGH3QYLc5FvivA@mail.gmail.com> (raw)
In-Reply-To: <6174F377-F1D9-40D1-9DD5-567AFD638B17@bluewin.ch>
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
On Sat, 21 Nov 2020 at 23:50, Phil <philip.hodges@bluewin.ch> wrote:
> The defect is already in HEAD and not just in that patch: ell/util.c calls isprint and toupper without a cast.
The isprint() parameter is an unsigned char, but the first toupper
call could in theory be passed unchecked char values...
>
> [My quick search for ctype did not find the macro definitions in "utf8.h". I didn't bother to look for the reserved identifiers to[a-z]+ and is[a-z]+ because it is quite fiddly to refine the regexp to not also match a lot of other identifiers. So I had no idea that the l_ascii_is* macros in utf8.h even existed, thanks for the tip. But utf8.h is only a partial replacement for <ctype.h> because there are no l_ascii_to* variants, and the names are off-putting, it looks like they are just for ascii not utf8. What value do they add to the ctype originals anyway, apart from providing the cast?]
>
> That validation won't help on affected platforms where char is signed 8 bit because every char <= 127.
Right, I didn't mean comparing char values against 127. Just that a
valid PEM file doesn't contain values > 127 but at that point in the
code we've not enforced this yet.
Best regards
next prev parent reply other threads:[~2020-11-21 23:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <814B09B7-CAAB-487B-9F42-8C0A2169A015@bluewin.ch>
2020-11-21 9:52 ` ctype.h undefined behaviour on signed char platforms, needs cast to (unsigned char) Phil
2020-11-21 20:29 ` Denis Kenzior
2020-11-21 20:57 ` Andrew Zaborowski
2020-11-21 22:49 ` Phil
2020-11-21 23:18 ` Andrew Zaborowski [this message]
2020-11-22 3:23 ` Denis Kenzior
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='CAOq732+x4g5-D=vXJNTgC=TT-Y4Y6axmoXWbMGH3QYLc5FvivA@mail.gmail.com' \
--to=andrew.zaborowski@intel.com \
--cc=ell@lists.01.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.