When I wrote all that stuff, I honestly wasn't even thinking about small objects. That being said, the facilities to interact with Objective-C objects is there.
Having a quick look at the code, however, it looks like toll-free bridging was never implemented for CFNumber. Essentially, every function needs a CF_OBJC_FUNCDISPATCHV call to the equivalent ObjC method + a NSCFNumber class needs to be created. Shouldn't be too hard, but I won't have time to get a better look until this weekend. There's also the OBJC_SMALL_OBJECT_MASK macro in objc/runtime.h that can be used to figure out if we're dealing with a small object. The ObjC dispatch macro should take care of all cases, though. Something to keep in mind: The toll-free bridging mechanism in GNUstep is not as seamless as the one in Cocoa. It would take a lot of extra development to beat it into shape, so major bugs are bound to exist. Regards Stefan On Fri, Nov 8, 2019, 07:58 David Chisnall <[email protected]> wrote: > Hi, > > There are a few different representations of numbers in the small object > representation. On 32-bit platforms, there is only small int, which has > the low bit set to 1 and stores a 32-bit integer in the remaining bits. > On 64-bit platforms, the low 3 bits indicate the type, with the > following values: > > 0: Object pointer > 1: Small int (61-bit integer) > 2: Small extended double (64-bit double, where the low bits of the > mantissa are represented) > 3: Small repeating double (64-bit double where the low bits are a short > repeated pattern. > 4: Unused > 5: Tiny string (8 7-bit ASCI characters, plus length). > 6: Unused > 7: Unused > > The numerical representations are defined in NSNumber: > > > https://github.com/gnustep/libs-base/blob/280b2cbe834007fa7945d783f3a538ecbaab52b5/Source/NSNumber.m#L374 > > > https://github.com/gnustep/libs-base/blob/280b2cbe834007fa7945d783f3a538ecbaab52b5/Source/NSNumber.m#L436 > > The tiny string representation is defined in GSString.m: > > > https://github.com/gnustep/libs-base/blob/dd368559230c485b1234695673f21b2269caca09/Source/GSString.m#L778 > > Note that, with the 2.0 ABI, the GSTinyString representation is emitted > by the compiler and so are considered part of the stable ABI. The other > number representations are not and are considered internal to the -base > implementation and may change between versions. I believe CoreBase is > version locked to base, so that isn't a problem. > > The code in CoreBase will need updating to check for the small number > representation. I'd be inclined to do this by moving some of the code > from NSNumber.m and GSString.m into a private header that can be shared > between base and CoreBase. > > David > > On 08/11/2019 11:18, Frederik Seiffert wrote: > > Hi all, > > > > I found that toll-free bridging of NSNumber to CFNumber crashes when > > using a "small object" (aka tagged pointer): > > > > NSNumber *num = @(42); > > NSLog(@"Type: %ld", (long)CFNumberGetType((__bridge CFNumberRef)num)); > > > > Crashes like this: > > > > * thread #1: tid = 27602, 0x00007fe328027ba0 > > libgnustep-corebase.so.0`CFNumberGetType > > [inlined] CFNumberGetType_internal(num=0x0000000000000151) at > > CFNumber.c:204, name = 'test', stop reason = invalid address (fault > > address: 0x15b) > > frame #0: 0x00007fe328027ba0 > > libgnustep-corebase.so.0`CFNumberGetType > > [inlined] CFNumberGetType_internal(num=0x0000000000000151) at > CFNumber.c:204 > > 201 CF_INLINE CFNumberType > > 202 CFNumberGetType_internal(CFNumberRef num) > > 203 { > > -> 204 return (CFNumberType)num->_parent._flags.info < > http://flags.info>; > > 205 } > > 206 > > 207 CF_INLINE CFIndex > > > > > > Note that 0x151 is a small int object for 42. Replacing 42 with e.g. > > INT_MAX (which doesn’t fit in a small object) makes the code work fine. > > > > Could anyone with knowledge of the corebase / small objects internals > > take a look at this, or point me in the right direction how to fix this? > > > > Related, there currently doesn’t seem to be a way to report bugs on > > corebase. Would it be possible to enable the bugtracker for the corebase > > GitHub project? > > > > Thanks! > > Frederik > > > >
