Tighten NSFileHandle retained NSError annotations#605
Conversation
Add narrow nullability annotations for the first Phase 4B core Foundation tranche without touching collection headers, module maps, or non-core surfaces. Keep the remaining judgment-call annotations conservative: - NSString legacy C-string decoding entry points stay nullable where decoding can return nil even though NULL C string inputs still raise. - NSURL initWithScheme:host:path: stays nullable because it funnels through initWithString:relativeToURL:, which can still fail for constructed non-ASCII URL text. - NSData bytes and mutableBytes stay nullable because zero-length concrete storage may legitimately expose a NULL backing pointer.
danjboyd
force-pushed
the
phase-15i-nsfilehandle-nserror-annotations
branch
from
f44b01d to
fc37667
Compare
|
Hi @danjboyd |
|
Thanks, agreed. These three PRs are stacked and intended for review/merge in order:\n\n1. #605 Phase 15I NSFileHandle NSError annotation slice\n2. #606 Phase 15J invalid keyed-unarchive runtime repair\n3. #607 Phase 15J NSKeyedArchiver/NSKeyedUnarchiver NSError annotation slice\n\nI opened them together to keep the current GNUstep Swift validation stack visible, but #606 and #607 can wait until #605 lands if that is easier for review. |
rfm
left a comment
rfm
left a comment
There was a problem hiding this comment.
I did a long review for this a few days ago, but it seems that it somehow got lost (perhaps I failed to notice an error response when I submitted it).
In short, the basic changes look good, but don't compile on even the limited set of test systems we use on github. It's a key requirement for GNUstep as a framework that it is portable code which makes it easier for developers to write portable code.
In this case it looks like the issue is compiler compatibility, and I think it's because the compatibility macros for nullability are in NSObjCRuntime.h (I don't know why, it probably seemed a good idea at the time). A quick fix would probably be to ensure that all the files which fail to compile import that header. A better fix might be to move those compatibility macros to a more commonly imported header file. Given that GSConfig.h is supposed to encapsulate portability issues found at configure time, perhaps we should put these (and other) portability macros dealing with compiler compatibility in GSConfig.h.in?
4 participants
Summary
Validation