Disappointed by GNUstep

[Wolfgang Lux]

Hi,

when I started looking at GNUstep as means to port macOS (then Mac OS X) 
applications to Linux/Windows about 15 years ago I found code that was quite 
buggy and that kept crashing or not working as expected on the application I 
tried to port at that time. I've contributed a number of patches to make the 
GNUstep code more robust since then.
In the past few years I hadn't time to contribute much to GNUstep (real life 
intervening at its worst), so fast forward to last Spring when I started 
looking back at that old hobby and was almost instantly greeted with another 
crash. Not having that much of time and energy I "fixed" the problem by just 
reverting to some revision of GNUstep gui/back shortly before the release of 
0.29.
Now, having accidentally updated the code to head again I had another look at 
this finding one cause for the crashes in NSPopUpButtonCell after a patch by 
Riccardo to avoid leaking the menu associated with the cell when the cell is 
deallocated. The patch looks correct to me, but the problem is that it uncovers 
another bug: The _selectedItem may contain a dangling pointer after setting the 
pop up button's menu to nil.
The next issue, that I'm currently unable to attribute to any particular patch, 
is a problem where a split view in a window loaded from a gorm file is calling 
a method on its delegate after that delegate (which is the window controller 
that has loaded the window in the first place) has been deallocated (and hence 
the window itself should have been closed at this point).
The first of this issues has a fairly straightforward fix and for the second 
one I might come up with a simple fix in my application to reset the split 
view's delegate in the window controller's dealloc method. However, what makes 
this so frustrating is that dangling pointers should not be an issue in the 
first place in 2022. Automatic reference counting and zeroing weak pointers 
have been around for a few years in clang and are supported the GNUstep 
Objective-C runtime. However, this project prefers to stick to obsolete 
technology (Richard mentioned gcc 4.0 as a baseline in another comment), which 
means ARC and weak pointers are not an option. So IMHO, in this regard people 
thinking this project is for nostalgics unfortunately is a well deserved 
characterization of this project. :-(

Wolfgang

PS I characterized gcc as obsolete technology because there is little support 
for Objective-C in gcc. The latest statement I seem to recall from another 
thread was that the gcc developers don't care about breaking objc support; but 
even if this weren't the case the Objective-C support is lagging far behind 
clang (in particular with regard to memory management, which IMO has always 
been one of the weak spots of Objective-C).