Weird Cast of Objective-C pointer type 'NSString *' to C pointer type 'CFStringRef' error

Question

I have seen that there are some topics with the "Cast of Objective-C pointer type 'NSString *' to C pointer type 'CFStringRef'" problem solved, but my case is slightly different.

I am doing some iOS cross compilation from linux and I have a local desktop pc with ubuntu where I can manage to compile without any issues all my code. When I try to port this into a AWS machine I get the following compilation error:

"Cast of Objective-C pointer type 'NSString *' to C pointer type 'CFStringRef'" on this code:

- (NSString *)stringByEscapingQueryString:(NSString *)string {
    return (NSString *)CFBridgingRelease(CFURLCreateStringByAddingPercentEscapes(NULL,
                                                                                 (CFStringRef)string,
                                                                                 NULL,
                                                                                 (CFStringRef) @":/?#[]@!$&'()*+,;=",
                                                                                 kCFStringEncodingUTF8));
}

using the following compilation command:

arm-apple-darwin11-clang -v -E  -I/home/ubuntu/source/common -I/home/ubuntu/source/ios -I/home/ubuntu/source/posix -I/home/ubuntu/generated_include  -fmessage-length=0     -fdiagnostics-show-note-include-stack   -fmacro-backtrace-limit=0   -fobjc-arc  -Wno-trigraphs  -fpascal-strings    -O0     -Wno-missing-field-initializers     -Wno-missing-prototypes     -Wno-return-type    -Wno-implicit-atomic-properties     -Wno-arc-repeated-use-of-weak   -Wno-missing-braces     -Wparentheses   -Wswitch    -Wno-unused-function    -Wno-unused-label   -Wno-unused-parameter   -Wno-unused-variable    -Wunused-value  -Wno-empty-body     -Wno-uninitialized  -Wno-unknown-pragmas    -Wno-shadow     -Wno-four-char-constants    -Wno-conversion     -Wno-constant-conversion    -Wno-int-conversion     -Wno-bool-conversion    -Wno-enum-conversion    -Wno-shorten-64-to-32   -Wpointer-sign  -Wno-newline-eof    -Wno-selector   -Wno-strict-selector-match  -Wno-undeclared-selector    -Wno-deprecated-implementations     -fstrict-aliasing   -Wprotocol  -Wno-sign-conversion -Wno-infinite-recursion    -Wmost  -Wno-four-char-constants    -Wno-unknown-pragmas -fmessage-length=0     -fdiagnostics-show-note-include-stack   -Wno-infinite-recursion     -Wmost  -w -fmessage-length=0   -fdiagnostics-show-note-include-stack   -fmacro-backtrace-limit=0   -fobjc-arc  -Wno-trigraphs  -fpascal-strings    -O0     -Wno-missing-field-initializers     -Wno-missing-prototypes     -Wno-return-type    -Wno-implicit-atomic-properties     -Wno-arc-repeated-use-of-weak   -Wno-missing-braces     -Wparentheses   -Wswitch    -Wno-unused-function    -Wno-unused-label   -Wno-unused-parameter   -Wno-unused-variable    -Wunused-value  -Wno-empty-body     -Wno-uninitialized  -Wno-unknown-pragmas    -Wno-shadow     -Wno-four-char-constants    -Wno-conversion     -Wno-constant-conversion    -Wno-int-conversion     -Wno-bool-conversion    -Wno-enum-conversion    -Wno-shorten-64-to-32   -Wpointer-sign  -Wno-newline-eof    -Wno-selector   -Wno-strict-selector-match  -Wno-undeclared-selector    -Wno-deprecated-implementations     -fstrict-aliasing   -Wprotocol  -Wno-sign-conversion    -Wno-infinite-recursion     -Wmost  -Wno-four-char-constants    -Wno-unknown-pragmas -fmessage-length=0     -fdiagnostics-show-note-include-stack   -Wno-infinite-recursion     -Wmost  -w -DW_DEBUG=1 -fvisibility=hidden -DBUILD_VARIATION=DEV -DFF_DEBUG_STRING_ID=1 -DFF_CRASH_HANDLING=1 -DGTEST_USE_OWN_TR1_TUPLE=1 -DENGINE_PLATFORM_IOS=1 -DUSECPP11=1 -miphoneos-version-min=6.0 -Wfatal-errors -Wno-return-type -g -arch arm64 -isysroot /home/ubuntu/ios-linux-cross-compile/cctools-port/usage_examples/ios_toolchain/target/SDK/iPhoneOS10.2.sdk   -o BFAppLinkNavigation.m.o   -c /home/ubuntu/source/ios/BFAppLinkNavigation.m

What's interesting about this is the following:
- Both machines have exactly same LLVM/Clang version: 3.9.1~svn288847-1~exp1
- Both machines are using exact same SDK (iPhoneOS10.2.sdk) - If I manually add on the AWS machine the "__bridged" attribute on the second parameter everything else compiles properly.
- I have compared the generated code with clang -E and the resulting file is exactly the same.

Do you guys have any idea of what can be done to solve this issue? I can't add the __bridged attribute to the files since OSX is not requiring them and I need to get the same compilation results.

I can provide more details if needed, I have already ran out of ideas :(

If compiling for macOS doesn't require `__bridge` for those casts, then you're not compiling for ARC there. In that case, the code will fail to do proper memory management. Make sure you're using ARC for both cases. Also, even if you're not using ARC, you can still use `__bridge`. It's just ignored in that case. Also, you can use `CFSTR("…")` for the 4th arg rather than an `NSString` that you cast. — Ken Thomases, Apr 04 '17 at 17:16
I have checked macOS compilation and it's using the -fobjc-arc argument so I guess that ARC is being used. My main problem is that this code comes from a third-party and I can't modify it (unless I apply a patch everytime) — slopee, Apr 04 '17 at 17:47
I might be going the wrong way about this but as I've read theoretically CFStringRef is under the CF_IMPLICIT_BRIDGING_ENABLED spell so it should not complain about this, right? — slopee, Apr 04 '17 at 18:21
Hmm, `CF_IMPLICIT_BRIDGING_ENABLED` is new to me. However, the [docs](http://clang.llvm.org/docs/AutomaticReferenceCounting.html#auditing-of-c-retainable-pointer-interfaces) for the underlying Clang feature say it applies to functions, not types. So, I don't think it eliminates the need for `__bridge` in these casts. But I'm not certain. — Ken Thomases, Apr 04 '17 at 21:40
If you compile in both places with `-v` in the compiler options, does the output showing the sub-tool invocations differ? Can you check the versions of those sub-tools? Maybe the front-end is identical but some back-end tool differs. — Ken Thomases, Apr 04 '17 at 21:42
Checked with -v in compiler options and the back-end tool seems to be the same in both cases, I'll double check just in case but seems legit :( — slopee, Apr 04 '17 at 23:11

score 0 · Accepted Answer · edited May 23 '17 at 10:30

I finally found the root cause of the problem. In my host machine I wasn't using CCache but on the AWS machine it was being used.

The AWS machine had an old CCache version where the run_second_cpp option was set to false and compilation was splitted into two steps: First run the preprocessor (with -E), check for a hit and in case that it wasn't found, compile the code with the previous preprocessor output. After changing it to "True" manually on the configuration everything started to work.

Main reason for this behaviour is explained here: Missing bridge cast causes error in preprocessed source but not in real source

Thanks Ken for your questions and help, they made me think a bit more and look around for more differences! Really appreciate it!

Weird Cast of Objective-C pointer type 'NSString *' to C pointer type 'CFStringRef' error

1 Answers1