Skip to content

Conversation

@hbugdoll
Copy link
Contributor

@hbugdoll hbugdoll commented Oct 1, 2025

Related to #14290. Edit: Also fixes #14306.

Description

Removed over 40 warnings during TitaniumKit build process:

  • Class method not found warnings
    • +resourceBasedURL:baseURL: in iphone/TitaniumKit/TitaniumKit/Sources/API/ScriptModule.m
      • added missing header file
  • Instance method not found warnings
    • -JSValueInContext: in iphone/TitaniumKit/TitaniumKit/Sources/API/KrollModule.m
      • added explicit cast
    • -applyProperties: in iphone/TitaniumKit/TitaniumKit/Sources/API/TiProxy.h
      • added to header file
  • Incompatible pointer types warnings
    • JSValueRef * vs. JSValueRef _Null_unspecified in iphone/TitaniumKit/TitaniumKit/Sources/API/TiBlob.m
      • use of JSValueRef, which is already a pointer (Edit: crash relevant)
      • added explicit initialization of JSValueRef
      • BTW removed unused JSValueRef *
    • CAShapeLayer * vs. CALayer * in iphone/TitaniumKit/TitaniumKit/Sources/API/TiUIView.m
      • added explicit cast
  • Receiver is a forward class and corresponding interface may not exist warnings
    • TiHost in iphone/TitaniumKit/TitaniumKit/Sources/API/ScriptModule.m
      • added missing header file
  • Receiver type warnings
    • NSUncaughtExceptionHandler * in iphone/TitaniumKit/TitaniumKit/Sources/API/TiExceptionHandler.m
      • added explicit cast
  • Enumeration value not handled in switch warnings
    • TiBlobTypeSystemImage in iphone/TitaniumKit/TitaniumKit/Sources/API/TiBlob.m
      • added missing default case

@hbugdoll hbugdoll mentioned this pull request Oct 1, 2025
25 tasks
@cb1kenobi cb1kenobi requested a review from hansemannn October 1, 2025 14:52
@hbugdoll hbugdoll closed this Oct 2, 2025
@hbugdoll hbugdoll deleted the titaniumkit-warnings-fix branch October 2, 2025 06:33
@hbugdoll hbugdoll restored the titaniumkit-warnings-fix branch October 2, 2025 06:38
@hbugdoll hbugdoll reopened this Oct 2, 2025
@hbugdoll hbugdoll changed the title fix(ios): reduced TitaniumKit build warnings fix(ios): reduced TitaniumKit build warnings & fixed TiBlob crash Oct 9, 2025
JSContext *context = JSContext.currentContext;
JSValueRef *exception;
JSObjectRef arrayBuffer = JSObjectMakeArrayBufferWithBytesNoCopy(context.JSGlobalContextRef, arrayBytes, len, jsArrayBufferFreeDeallocator, nil, exception);
JSObjectRef arrayBuffer = JSObjectMakeArrayBufferWithBytesNoCopy(context.JSGlobalContextRef, arrayBytes, len, jsArrayBufferFreeDeallocator, nil, NULL);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why passing NULL here instead of initializing the exception to NULL and passing the reference like you did below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because exception is not evaluated resp. used further here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should though - any exception handling can be useful

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But how?
Handling it like in arrayBuffer via KrollPromise then it would make toArrayBuffer and arrayBuffer redundant.

Handling it with the JavaScriptCore API (I am not familiar with it), ChatGPT suggests the following:

    if (exception) {
        JSStringRef exceptionStr = JSValueToStringCopy(context.JSGlobalContextRef, exception, NULL);
        NSString *message = (__bridge_transfer NSString *)JSStringCopyCFString(kCFAllocatorDefault, exceptionStr);
        JSStringRelease(exceptionStr);

        // e.g. handle message
        
        free(arrayBytes);
        return nil;
    }

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mhh, we are there even both then, if the only difference is the exception?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, there is still a difference – a different context may be used (JSContext.currentContext vs. [self currentContext]).

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

iOS: Test app crashes on [TiBlob arrayBuffer]

2 participants