[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: netsec 682578f 4/6: Add option to bypass NSM TLS checks on local net

From: Robert Pluim
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

Robert Pluim <address@hidden> writes:

> Eli Zaretskii <address@hidden> writes:
>>> From: Robert Pluim <address@hidden>
>>> Cc: address@hidden
>>> Date: Tue, 17 Jul 2018 12:09:10 +0200
>>> Eli Zaretskii <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]