KDE3.4RC1: Incompatibility

Bernhard Rosenkraenzer bero at arklinux.org
Mon Mar 14 22:22:48 GMT 2005


On Monday 14 March 2005 21:45, Scott Wheeler wrote:
> But you won't get around that with a C API.  Without operator overloading
> you can't fix:
>
> GString *s = g_string_new("foo");
> gchar c = s[10];
>
> Even if you reimplement the API in Qt, you'd still have just overrun some
> buffer.  Where glib offers such things semantically (i.e. GList), the
> bounds are also checked.

So let's fix the code that uses it (by making it use Qt or at least libstdc++) 
rather than reinventing the same crap --- the problem with glib isn't that 
it's huge or that its memory footprint is extremely large, the problem is 
that it's an inherently broken way to implement things (as proven by this 
example), and that it's completely superfluous, it doesn't do anything Qt or 
libstdc++ won't do...

Fixing the apps that use it to use something else (QtCore from Qt 4.0 seems a 
good choice) shouldn't be too hard, just time consuming...




More information about the kde-core-devel mailing list