Skip to content

Fix CFInfo on 64-bit big endian platforms. #1709

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

mundaym
Copy link
Contributor

@mundaym mundaym commented Sep 27, 2018

Prior to this change 64-bit platforms treated _cfinfoa as both a
64-bit and 32-bit variable. When accessing _cfinfoa as a 32-bit
variable the code makes the assumption that it is accessing the
lowest (or rightmost) bits of _cfinfoa. Unfortunately on big-endian
platforms it is actually accessing the high (or leftmost) bits.

Fix this issue by unconditionally treating _cfinfoa as a 64-bit
value when targeting a 64-bit platform.

@@ -87,7 +87,13 @@ extension ObjCBool : CustomStringConvertible {
#endif

internal class __NSCFType : NSObject {
#if arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le)
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we not have a word-size macro like C does here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not that I could find sadly. This seems to be the standard way to do it at the moment:

Foundation/NSSwiftRuntime.swift:90:#if arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le)
Foundation/NSObjCRuntime.swift:218:#if arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le)
Foundation/CGFloat.swift:16:#elseif arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le)
Foundation/CGFloat.swift:188:#elseif arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le)
Foundation/NSNumber.swift:710:        #if arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le)
Foundation/NSNumber.swift:718:    #if arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le)
Foundation/NSRange.swift:129:        #elseif arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64le)
Foundation/NSRange.swift:391:#elseif arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le)
TestFoundation/TestNSNumber.swift:1061:        #if arch(x86_64) || arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le)

Copy link
Contributor

Choose a reason for hiding this comment

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

This change also conflicts with a backout we've been trying to do for 32-bit that keeps getting shuffled, reopened, and closed, and expected to be re-opened again. And really, this particular use should be a _CFInfo, not a raw Int.

Copy link
Contributor

Choose a reason for hiding this comment

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

Because this _cfinfo should match the size of _CFInfo

Copy link
Contributor

Choose a reason for hiding this comment

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

See #1693 (which is a followup of #1689 which attempted a similar forward fix as you are applying to 32-bit with this change).

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm fine with taking this change in lieu of #1693, but I'd prefer it if we took the _CFInfo implementation from #1689 which uses UInt and avoids macros.

@parkera
Copy link
Contributor

parkera commented Sep 27, 2018

Seems reasonable. Want to make sure this lines up with the work @millenomi is doing to merge right now.

@Kaiede
Copy link
Contributor

Kaiede commented Sep 28, 2018

In addition to the specific comment, I'll point out that #1689 already fixes _CFInfo in a cleaner way, but was rejected in favor of a revert. I'd recommend borrowing the implementation from the swift files.

@millenomi
Copy link
Contributor

As soon as I'm finished with the merge, I want to sit down and figure out what is the best solution here. #1694 we want for sure, and let's chat about the definition in CFRuntimeBase.

@Kaiede
Copy link
Contributor

Kaiede commented Sep 28, 2018

Is there a Slack or something we can use for the three of us for that? Right now, Arm32 and i686 have been having to use patches to build 4.1, 4.2, or the master branch and not immediately segfault. So I've been chomping at the bit and disappointed at the cycle of PRs on this issue for a couple weeks now.

#1694 isn't even the blocking issue for us. :(

@millenomi
Copy link
Contributor

Yeah, sorry; it's just been a bit of bad timing at the moment because of the behind-the-scenes work for the merge.

You can contact me via private message on the Swift forums if necessary!

@millenomi
Copy link
Contributor

And I can also see to set up something for multiple people if needed.

@Kaiede
Copy link
Contributor

Kaiede commented Sep 28, 2018

Since we're hijacking @mundaym's PR for this, it's only fair to bring them to the table as well, I think?

@millenomi
Copy link
Contributor

millenomi commented Oct 10, 2018

@Kaiede @mundaym @johnno1962 Can you join a Slack space (via this link) to discuss the direction of this?

@Kaiede
Copy link
Contributor

Kaiede commented Oct 10, 2018

Worked for me.

Prior to this change 64-bit platforms treated _cfinfoa as both a
64-bit and 32-bit variable. When accessing _cfinfoa as a 32-bit
variable the code makes the assumption that it is accessing the
lowest (or rightmost) bits of _cfinfoa. Unfortunately on big-endian
platforms it is actually accessing the high (or leftmost) bits.

Fix this issue by unconditionally treating _cfinfoa as a 64-bit
value when targeting a 64-bit platform.
@mundaym
Copy link
Contributor Author

mundaym commented Aug 5, 2019

@swift-ci Please test.

@mundaym
Copy link
Contributor Author

mundaym commented Aug 5, 2019

Hi, I've brought this PR up to date with the changes upstream. Can you take another look? Thanks!

@mundaym
Copy link
Contributor Author

mundaym commented Aug 13, 2019

Friendly ping.

@levivic
Copy link

levivic commented Sep 20, 2019

friendly ping

@johnno1962
Copy link
Contributor

ping

@shahmishal shahmishal closed this Oct 6, 2020
@shahmishal
Copy link
Member

The Swift project moved the default branch to main and deleted master branch, so GitHub automatically closed the PR. Please re-create pull request with main branch.

More detail about the branch update - https://forums.swift.org/t/updating-branch-names/40412

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.

7 participants