[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
NSNotificationCenter's pointer abuse
From: |
David Chisnall |
Subject: |
NSNotificationCenter's pointer abuse |
Date: |
Wed, 8 May 2013 07:34:18 -0400 |
Compiling NSNotificationCenter with the latest clang gives me these errors:
In file included from NSNotificationCenter.m:262:
../Headers/GNUstepBase/GSIMap.h:466:3: warning: bitmasking for introspection of
Objective-C object pointers is
strongly discouraged [-Wdeprecated-objc-pointer-introspection]
GSI_MAP_RELEASE_KEY(map, node->key);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NSNotificationCenter.m:243:61: note: expanded from macro 'GSI_MAP_RELEASE_KEY'
#define GSI_MAP_RELEASE_KEY(M, X) ({if ((((uintptr_t)X.obj) & 1) == 0) \
~~~~~~~~~~~~~~~~~~ ^
In file included from NSNotificationCenter.m:262:
../Headers/GNUstepBase/GSIMap.h:1183:8: warning: bitmasking for introspection
of Objective-C object pointers is
strongly discouraged [-Wdeprecated-objc-pointer-introspection]
GSI_MAP_RELEASE_KEY(map, node->key);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NSNotificationCenter.m:243:61: note: expanded from macro 'GSI_MAP_RELEASE_KEY'
#define GSI_MAP_RELEASE_KEY(M, X) ({if ((((uintptr_t)X.obj) & 1) == 0) \
~~~~~~~~~~~~~~~~~~ ^
The error exists because in recent runtimes (GNUstep and Apple), some small
objects are stored inside pointers and so you should not set or inspect the low
bits unless you really know what you're doing. This code, however, predates
that and the assumption wasn't caught up until now.
The low bit is used for two purposes: to 'hide' some pointers from GC (I'm not
sure why this needs to be done, as we should be using zeroing weak references
for that, and do appear to be doing so, and, perhaps more importantly, we don't
want objects to be deallocated but leave dangling pointers in GC mode), and to
differentiate between keys and objects.
The latter is problematic, because we will potentially have cases where this
differentiation is flawed (in particular, if a notification has a very short
string name). It's not totally clear to me that this ought to be needed,
because it seems that we store them in different map tables. Is this just a
limitation of GSIMap (only allowing one map table type per compilation unit)?
In which case we could remove it by using NSMapTable.
David
-- Sent from my Cray X1
- NSNotificationCenter's pointer abuse,
David Chisnall <=