[StrictMemorySafety] Add unsafe annotations to OpenBSDImpl. #86616
Conversation
|
@swift-ci please test. |
|
Can we use |
3405691582
force-pushed
the
mutex_safety
branch
from
7c47059 to
68ee5d5
Compare
Good catch. Updated; I think I've done so appropriately. |
|
I'd use |
In swiftlang#86276 strict memory safety becomes an error, necessitating adding the following annotations and changes: * in init(): check the return value of `pthread_mutex_init`; since this isn't a failable initializer, `fatalError` if this fails, to avoid silently leaving a zero-valued pointer, * similarly check return values in `pthread_mutex_lock`, `pthread_mutex_unlock`, and `pthread_mutex_destroy`, * the message in `fatalError` should use `strerror_r`, which necessitates `unsafe` markings since it initializes the array storage unsafely. * marking the `value` as `@safe` since the underlying mutex type is an `OpaquePointer` and is unsafe and all access to value occur through a safe interface, * thus, marking `_MutexHandle` `@safe`.
3405691582
force-pushed
the
mutex_safety
branch
from
68ee5d5 to
6e31926
Compare
Done. That certainly looks more idomatic now. |
grynspan
left a comment
grynspan
left a comment
There was a problem hiding this comment.
You're not quite holding the Array API right as-is. How about this instead? It avoids an intermediate heap allocation for the buffer and it uses a fallback string that still vends the error code.
Co-authored-by: Jonathan Grynspan <[email protected]>
|
(Oh -- I just noticed I was using Array's withUnsafeTemporaryAllocation instead of String's like you originally suggested. 🤦♀️) |
|
@swift-ci please test. |
|
|
||
| @usableFromInline | ||
| @_transparent | ||
| func errstr(_ no: Int32) -> String { |
There was a problem hiding this comment.
Does the OpenBSD implementation call strerror() elsewhere? Not for this PR, but would be worth auditing the codebase and replacing such calls with something like this function in the future. (Same for FreeBSD.)
There was a problem hiding this comment.
Not that I'm aware of, but making this more accessible is probably a good idea...
...as well as adding other affordances for interacting with libc, which again, is another good fit with the import C pitch...
|
@swift-ci please test. |
2 participants
In #86276 strict memory safety becomes an error, necessitating adding the following annotations and changes:
in init(): check the return value of
pthread_mutex_init; since this isn't a failable initializer,fatalErrorif this fails, to avoid silently leaving a zero-valued pointer,similarly check return values in
pthread_mutex_lock,pthread_mutex_unlock, andpthread_mutex_destroy,the message in
fatalErrorshould usestrerror, which necessitatesunsafemarkings since despitestrerrornever returning a null pointer.marking the
valueas@safesince the underlying mutex type is anOpaquePointerand is unsafe and all access to value occur through a safe interface,thus, marking
_MutexHandle@safe.