Re: [dev] Different versions of suckless libutf

From: Ben Woolley <tautolog_AT_gmail.com>
Date: Wed, 1 Jun 2016 09:54:13 -0700

> On Jun 1, 2016, at 9:12 AM, Kamil Cholewiński <harry666t_AT_gmail.com> wrote:
>
>> On Wed, 01 Jun 2016, Ben Woolley <tautolog_AT_gmail.com> wrote:
>> I see two things to do:
>> 1. There could be a new name for the transformation that stands apart
>> from UTF-8, which has now been changed from that original meaning.
>> [...]
>>
>> Maybe call the transform CTF-8, where C is character. Then UTF-8 is
>> just a wrapper around CTF-8. Then a comment explaining what CTF stands
>> for and what it does should be sufficient.
>>
>> Then there can be libctf and libutf living in cognitive harmony.
>>
>> Instead of CTF, it could be called ur-UTF in liburutf. Then it would
>> literally be urtext, which would be mildly amusing at least to me.
>
> Oy, this will cause infinite neverending confusion and multiply the
> mess, let alone it just plain won't take off. Most laydevs I know
> already can't tell the difference between UTF8 and Unicode.
>

The main point is actually to cause a pause so that people will need to think about the meanings of things, rather than letting connotations spoil things. This whole thread started because of confusion over what code was appropriate where.

> Looks like we're creating problems out of thin air here.
>

There is a legit problem. This exact issue of when validation occurs actually caused a worldwide Internet worm years ago. That is the reason why I am erring on the side of 5% this time.

> Find the 95% use case and cater to it.

I would normally agree with this sentiment. I was originally skeptical of the desire to separate the functions because of the security concerns myself, but the naming issue came up, so there is a valid argument that there may be "suck" that needs to be worked with rather than just ignoring.

And if an author wants to cater to an additional 5%, I think that that is their prerogative.

In this case, I see the desire in having a library that didn't need tracking standards for maintenance, and having another that was all about tracking the latest standard.

>
> <3,K.
Received on Wed Jun 01 2016 - 18:54:13 CEST