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-5046] Difficult to pass nil as CVarArg to withVaList #47622

Open
jtbandes opened this issue May 29, 2017 · 1 comment
Open

[SR-5046] Difficult to pass nil as CVarArg to withVaList #47622

jtbandes opened this issue May 29, 2017 · 1 comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella

Comments

@jtbandes
Copy link
Collaborator

Previous ID SR-5046
Radar None
Original Reporter @jtbandes
Type Bug
Additional Detail from JIRA
Votes 1
Component/s Standard Library
Labels Bug
Assignee None
Priority Medium

md5: c0f9dc163657df2f789b8f767a83856a

Issue Description:

Since the stdlib pointer types started representing null pointers as Optional.none, it has become difficult to pass a null pointer as a CVarArg.

Here is a working example from Stack Overflow user MartinR: https://stackoverflow.com/a/32064355

let nullPtr = unsafeBitCast(0, to: OpaquePointer.self)
let otherTitles : [CVarArg] = otherButtonTitles + [nullPtr]
getVaList(...)/withVaList(...)

Having to use unsafeBitCast is awkward; it would be better if a null pointer could be used directly in this context. Perhaps the right solution is something like extension Optional: CVarArg where Wrapped == OpaquePointer/UnsafePointer/.... (For that matter, it would also be nice to have an easier way to obtain a null OpaquePointer, perhaps something like init?() { return nil }.)

@belkadan
Copy link
Contributor

We don't have conditional conformances, and we won't have conditional conformances that can apply in multiple ways. Our official recommendation right now is to just use 0 as Int, since Int is guaranteed to be word-sized and has the same C variadic calling conventions as a pointer on all platforms supported by Swift, but we could also have some kind of special CVarArgNil type.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
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. standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

2 participants