gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] Minor fix for strings initialised with data they don't


From: Alexander Malmberg
Subject: Re: [Gnustep-cvs] Minor fix for strings initialised with data they don't own ... consistent [...]
Date: Sun, 02 Nov 2003 02:44:43 +0100

> + Sat Nov 01 11:10:00 2003  Richard Frith-Macdonald <address@hidden>
> + 
> +       * Source/NSString.m: ([-copyWithZone:]) always do true copy
> +       * Source/GSString.m: Where the string data pointed to is not
> +       owned by the string instance, have copy operations create new
> +       instances rather than retaining the receiver.

This broke -gui pretty badly. When looking at fixing it, I found that it
couldn't be fixed cleanly. Stepping back a bit, it became apparent that
this is due to a design flaw in the class hierarchy under GSString. For
now, I've committed a temporary workaround, so -gui should mostly work.

The problem with GSString et al is that there are two properties of
concrete classes in the hierarchy, which I'll call "structure" (8-bit
data vs. unicode), and "memory management" (allocated buffers vs. inline
vs. substrings ...), and these are mixed in the class hierarchy (in this
case, "memory management" methods are leaking to subclasses with
incompatible "memory management"). Apart from breaking all kinds of
design rules, this makes it harder to understand the classes, and thus
harder to keep it working, and it makes it easy to add latent bugs.

Anyway, my plan is to remove all memory management related methods from
GSString, GSCString, and GSUnicodeString and make then clean, abstract
'structure' classes. Memory management will be defined by leaf classes
(the concrete classes), so there'll be an extra pair of subclasses of
GSCString and GSUnicodeString that use external buffers (that may or may
not be owned by the instance; the memory management code currently in
GS{,C,Unicode}String will end up here).

Since the 'structure' parts' interest in the memory management can be
summed up in a single simple "is my buffer guaranteed to be valid at
least until I am released"-flag (equivalent to the current 'free'-flag
for the external buffer case), this will work out nicely and should fix
this and any other bugs caused by leaking non-owned buffers.

Any thoughts before I get to work on this?

- Alexander Malmberg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]