Re: Implementation of SASLprep for SCRAM-SHA-256

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Implementation of SASLprep for SCRAM-SHA-256
Date: 2017-04-06 17:47:12
Message-ID: 4dce3d79-7990-9a02-87f7-ab5b1b5aca81@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/06/2017 08:42 PM, Heikki Linnakangas wrote:
> D'oh. Here's a new version, with saslprep.h included.

And here it is for real. Sigh.

>> There is for example this portion in the new tables:
>> +static const Codepoint prohibited_output_chars[] =
>> +{
>> + 0xD800, 0xF8FF, /* C.3, C.5 */
>>
>> ----- Start Table C.5 -----
>> D800-DFFF; [SURROGATE CODES]
>> ----- End Table C.5 -----
>> This indicates a range of values. Wouldn't it be better to split this
>> table in two, one for the range of codepoints and another one with the
>> single entries?
>
> I considered that, but there are relatively few singular codepoints in
> the tables, so it wouldn't save much space. In this patch, singular
> codepoints are represented by a range like "0x3000, 0x3000".
>
>> + 0x1D173, 0x1D17A, /* C.2.2 */
>> This is for musical symbols. It seems to me that checking for a range
>> is what is intended.
>
> Can you elaborate?

Oh, I think I understand the confusion now. All the arrays represent
codepoint ranges, not singular codepoints. I renamed them to "*_ranges",
to make that more clear.

- Heikki

Attachment Content-Type Size
implement-SASLprep-6.patch.gz application/gzip 71.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message mark 2017-04-06 18:10:05 Re: Postgresql10 Bug report. (pg_catalog.pg_statistic_ext does not exist)
Previous Message Heikki Linnakangas 2017-04-06 17:42:58 Re: Implementation of SASLprep for SCRAM-SHA-256