Strake dixit:
>Use wchar.h functions and a sane libc, e.g. musl, which has a pure
>UTF-8 C locale, which ISO C explicitly allows [1].
>
>The 8-bit clarity what POSIX wants [1] seems nonsense to me, as one
>can use byte functions for that, but I may be wrong.
^^
Not always, see
On Tue, Dec 24, 2013 at 01:07:10PM -0500, Strake wrote:
> On 24/12/2013, Silvan Jegen wrote:
> > So I guess the question boils down to whether you would rather use
> > libutf or the standardized, POSIX-locale-dependent wchar.h functions for
> > the UTF-8 conversion. I see one advantage of the wch
On 24/12/2013, Silvan Jegen wrote:
> So I guess the question boils down to whether you would rather use
> libutf or the standardized, POSIX-locale-dependent wchar.h functions for
> the UTF-8 conversion. I see one advantage of the wchar.h functions:
> If we use them we could avoid adding an extern
On Tue, Dec 24, 2013 at 05:20:08PM +0100, Silvan Jegen wrote:
> So I guess the question boils down to whether you would rather use
> libutf or the standardized, POSIX-locale-dependent wchar.h functions for
> the UTF-8 conversion. I see one advantage of the wchar.h functions:
> If we use them we co
On Thu, Nov 28, 2013 at 12:45:40PM +0200, sin wrote:
> On Tue, Nov 26, 2013 at 12:01:01PM -0800, Silvan Jegen wrote:
> > If you you would rather not take this version, what approach would
> > you take for the character set mapping when using UTF-8? A hashmap-,
> > or B-tree-based solution or someth
Heyho,
I noticed many CLOSE_WAIT connections from surf in the output of `lsof -i -an`
after browsing some websites with surf. Before blaming someone or trying to fix
it: Is this expected behaviour? Or should it be fixed?
Merry Christmas.
--Markus
