Skip to content

Return NSError for invalid keyed unarchive data#606

Open
danjboyd wants to merge 11 commits into
gnustep:masterfrom
danjboyd:phase-15j-nskeyedunarchiver-invalid-data-error
Open

Return NSError for invalid keyed unarchive data#606
danjboyd wants to merge 11 commits into
gnustep:masterfrom
danjboyd:phase-15j-nskeyedunarchiver-invalid-data-error

Conversation

@danjboyd
Copy link
Copy Markdown

@danjboyd danjboyd commented May 4, 2026

Summary

  • Catch invalid-data exceptions in the newer NSKeyedUnarchiver error-bearing convenience APIs.
  • Return nil and populate NSError instead of letting invalid archive data terminate the process.
  • Add focused NSKeyedArchiver regression coverage for invalid data.

Validation

  • PATH=/usr/GNUstep/System/Tools:$PATH make
  • PATH=/usr/GNUstep/System/Tools:$PATH make check testobj=NSKeyedArchiver/general.m
  • GNUSTEP_SWIFT_BASE_LIBDIR_OVERRIDE=/home/danboyd/git/gnustep/libs-base/Source/obj scripts/run-phase15j-nskeyedarchiver-nserror-runtime-gate.sh

@danjboyd danjboyd requested a review from rfm as a code owner May 4, 2026 19:22
dboyd-invitoep and others added 11 commits May 4, 2026 15:55
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 danjboyd force-pushed the phase-15j-nskeyedunarchiver-invalid-data-error branch from ec4c026 to 796e38a Compare May 4, 2026 20:59
@danjboyd
Copy link
Copy Markdown
Author

danjboyd commented May 5, 2026

Stack note: this PR depends on #605 and should be reviewed/merged after #605. The intended order is #605, then #606, then #607.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants