Skip to content
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

[SR-466] Imported APIs taking chars should use CChar #43083

Closed
lhoward opened this issue Jan 4, 2016 · 10 comments
Closed

[SR-466] Imported APIs taking chars should use CChar #43083

lhoward opened this issue Jan 4, 2016 · 10 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself good first issue Good for newcomers

Comments

@lhoward
Copy link
Contributor

lhoward commented Jan 4, 2016

Previous ID SR-466
Radar None
Original Reporter @lhoward
Type Bug
Status Closed
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, ClangImporter, StarterBug
Assignee @dduan
Priority Medium

md5: fb3d11a5978519172603e14b926036d4

Issue Description:

I don’t know if/when Swift will be ported to a platform where the character type is unsigned but perhaps imported APIs where the character signedness is not explicitly specified should be imported as CChar rather than Int8?

Documentation says that CChar is the native character type.

@belkadan
Copy link
Contributor

belkadan commented Jan 4, 2016

@DougGregor, @lattner, any opinions?

@DougGregor
Copy link
Member

Seems reasonable to me.

@lattner
Copy link
Mannequin

lattner mannequin commented Jan 5, 2016

I don't have a strong opinion on it, I was sort of hoping that all the C* types would go away someday. I agree that in this case, CChar does serve a useful purpose though.

@Dante-Broggi
Copy link
Contributor

Is this resolved or no longer being considered? If so, it should be closed.

@belkadan
Copy link
Contributor

I think we could still do it. It's not ABI-breaking, since the CChar typealias is fixed for each platform. (We also don't have a CSignedChar, which we'd probably want.)

@groue
Copy link

groue commented Feb 28, 2019

If imported APIs would expose a CChar instead of a raw Int8 or Uint8, we could avoid the illusion of a mismatch with other Swift APIs. For example, String.utf8CString returns a ContiguousArray<CChar>. If we had CChar everywhere, no one would ever wonder how to write correct platform-independent code.

This message is a follow-up of https://forums.swift.org/t/is-there-is-mismatch-between-string-utf8cstring-and-imported-c-declarations/21013

@belkadan
Copy link
Contributor

Tagging as a StarterBug. All the pieces for this are in place, so what's left is:

1. Remove the entries for Char_U, Char_S, WChar_S, and WChar_U from BuiltinMappedTypes.def. These represent char and wchar_t without explicit signedness, and won't disturb signed char and unsigned char.
2. Add cases for those four types to VisitBuiltinType in ImportType.cpp. These cases should do the same thing as the ones generated for the entries in BuiltinMappedTypes.def, but without the unwrapCType call.
3. Update all the tests that change because of this.

@benrimmington
Copy link
Collaborator

If wchar_t will be imported as CWideChar, the typealias might need to be updated (e.g. 16-bit on Windows, I think). However, portability wouldn't be improved with CWideChar, if it uses Unicode.Scalar on Darwin, and Int16 or UInt16 on Windows.

@belkadan
Copy link
Contributor

It's already using CWideChar; the only difference is that it looks through the typealias at the point of import, and now we'll be preserving the typealias. That won't change anything in the ABI.

@dduan
Copy link
Collaborator

dduan commented Jul 2, 2020

I ran into this, discovered the forum post, which lead me here. #32692

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

7 participants