Am Montag, den 11.08.2008, 11:48 -0400 schrieb Behdad Esfahbod:
> > Hmm... Early validation of our strings, not that stupid. Here some
> > starting port for brain storming:
> >
> > struct _GString
> > {
> > gchar *str;
> > gsize len;
> > gsize all
Am Montag, den 11.08.2008, 12:53 +0100 schrieb adrian.dmc:
> Hmm... Early validation of our strings, not that stupid. Here some
> starting port for brain storming:
>
> struct _GString
> {
> gchar *str;
> gsize len;
> gsize allocated_len;
> gboolean tainted : 1;
> };
>
> Let's add the important g_ut
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mathias Hasselmann wrote:
> Am Montag, den 11.08.2008, 12:53 +0100 schrieb adrian.dmc:
>> Hi...
>>
>> I included the ASCII only version to remove the overhead when dealing
>> with lowercasing, uppercasing, decimal or hexadecimal digits and
>> things li
(Duo to a mistake I'm re-sending this message...)
>struct _GString
>{
> gchar *str;
> gsize len;
> gsize allocated_len;
> gboolean tainted : 1;
>};
>
> Let's add the important g_utf8_ functions to g_string, and let them
> operate without
2008/8/11 Mathias Hasselmann <[EMAIL PROTECTED]>:
>
> Remains the question: Why are their ASCII only versions of all those
> functions. Dunno. Legacy? Performance? Side note: Why don't have Intel's
> fancy processors some g_utf8_next_char() function yet?
The reason there are ASCII-only versions of
Am Montag, den 11.08.2008, 12:53 +0100 schrieb adrian.dmc:
> Hi...
>
> I included the ASCII only version to remove the overhead when dealing
> with lowercasing, uppercasing, decimal or hexadecimal digits and
> things like that from applications that really don't need to bring the
> complexity of U
Hi...
I included the ASCII only version to remove the overhead when dealing with
lowercasing, uppercasing, decimal or hexadecimal digits and things like that
from applications that really don't need to bring the complexity of Unicode
to them. As an example GTK signal strings could only use the ASC
> Strings in glib/gtk always are UTF-8. Always.
Not *all* strings. I would say for GTK+ what you say is true (except
for file names), but GLib has many APIs that deal with nl-terminated
generic C strings that don't have to be in any consistent encoding at
all, or for file names are in the "GLib fi
Am Montag, den 11.08.2008, 09:13 +0200 schrieb Colin Leroy:
> On Mon, 11 Aug 2008 09:10:10 +0200, Mathias Hasselmann wrote:
>
> Hi,
>
> > They needlessly limit the range of
> > characters a application can process, and even more important: They
> > add a vast amount of complexity to your program
On Mon, 11 Aug 2008 09:10:10 +0200, Mathias Hasselmann wrote:
Hi,
> They needlessly limit the range of
> characters a application can process, and even more important: They
> add a vast amount of complexity to your program. Programmers really
> should not have to think about locale issues.
Emai
Am Samstag, den 09.08.2008, 19:01 +0100 schrieb adrian.dmc:
> Hi...
>
> Following my previous e-mail I'll present were my ideas for changing
> the support for strings in GLIb.
>
> When I look at the string functions in Glib there is a lot of
> inconsistency: error checking, what character set is
Hi...
Following my previous e-mail I'll present were my ideas for changing the
support for strings in GLIb.
When I look at the string functions in Glib there is a lot of inconsistency:
error checking, what character set is supported and function naming; so I'm
proposing to change, at least, the f
Hi...
My first objective here was to redesign the Unicode property tables but I
realized that it is the wrong starting point to start developing so as the
title suggest I propose myself to optimize the basic string support of GLib
(gstring, gstrfuncs and others) I already started optimizing the gu
13 matches
Mail list logo
