From: Robert Pluim <rpluim@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: netsec 682578f 4/6: Add option to bypass NSM TLS checks on local networks
Date: Tue, 17 Jul 2018 18:17:57 +0200 [thread overview]
Message-ID: <87r2k1g7ka.fsf@gmail.com> (raw)
In-Reply-To: <87va9dg8oa.fsf@gmail.com> (Robert Pluim's message of "Tue, 17 Jul 2018 17:53:57 +0200")
Robert Pluim <rpluim@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Robert Pluim <rpluim@gmail.com>
>>> Cc: emacs-devel@gnu.org
>>> Date: Tue, 17 Jul 2018 12:09:10 +0200
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> >
>>> > Then I think we should test that it's either a unibyte string or a
>>> > string whose size in bytes is equal to its size in characters, and
>>> > signal an error if that doesn't hold.
>>>
>>> So I tried using STRING_MULTIBYTE, but of course eww uses
>>> puny-encode-domain on unicode hostnames, and that returns a multibyte
>>> string that only contains ASCII characters. Rather than opening that
>>> can of worms, I settled on checking
>>>
>>> SBYTES (host) != SCHARS (host)
>>
>> This will signal an error for unibyte strings, because there SBYTES is
>> always -1. So I think you should do this instead:
>>
>
> Ah, I was assuming they'd always be in sync.
>
>> STRING_MULTIBYTE (host) && SBYTES (host) != SCHARS (host)
>
> OK, that works.
I couldn't get my original to fail with a unibyte string. Turns out
that even though size_byte is indeed -1 for unibyte strings, in that
case SBYTES returns the size field:
ptrdiff_t nbytes = s->u.s.size_byte < 0 ? s->u.s.size : s->u.s.size_byte;
Having said that, testing for STRING_MULTIBYTE is harmless.
Robert
next prev parent reply other threads:[~2018-07-17 16:17 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180714170806.8972.58581@vcs0.savannah.gnu.org>
[not found] ` <20180714170809.C3A3920456@vcs0.savannah.gnu.org>
2018-07-15 11:46 ` netsec 682578f 4/6: Add option to bypass NSM TLS checks on local networks Robert Pluim
2018-07-15 15:34 ` Jimmy Yuen Ho Wong
2018-07-16 13:34 ` Robert Pluim
2018-07-16 15:00 ` Eli Zaretskii
2018-07-16 15:24 ` Jimmy Yuen Ho Wong
2018-07-16 17:59 ` Eli Zaretskii
2018-07-16 16:23 ` Robert Pluim
2018-07-16 17:16 ` Jimmy Yuen Ho Wong
2018-07-16 17:46 ` Robert Pluim
2018-07-16 18:09 ` Eli Zaretskii
2018-07-17 10:09 ` Robert Pluim
2018-07-17 15:50 ` Eli Zaretskii
2018-07-17 15:53 ` Robert Pluim
2018-07-17 16:17 ` Robert Pluim [this message]
2018-07-17 17:15 ` Eli Zaretskii
2018-07-17 18:00 ` Robert Pluim
2018-07-16 15:31 ` Jimmy Yuen Ho Wong
2018-07-16 16:14 ` Stefan Monnier
2018-07-16 16:36 ` Robert Pluim
2018-07-16 18:11 ` Eli Zaretskii
2018-07-16 18:24 ` Stefan Monnier
2018-07-16 17:06 ` Andy Moreton
2018-07-16 17:15 ` Jimmy Yuen Ho Wong
2018-07-16 17:48 ` Paul Eggert
2018-07-17 5:56 ` Robert Pluim
2018-07-17 18:07 ` Robert Pluim
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=87r2k1g7ka.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=emacs-devel@gnu.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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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.