IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Several commonly used APIs currently unnecessarily return
`Option<T>`, like `ostree_deployment_get_csum()`.
Flip the gir flag for this to on; I think our annotations are
correct.
Specifically, I verified that *before* the previous patch to the
ed25519 C code, the last bit of code would fail with a SIGSEGV when
trying to read the empty signature.
The pattern this API uses in C is to allow the input parameters
pointer targets to be `NULL`, and it doesn't return values in that
case.
A further complexity here is that the API will still return `NULL`
for symbolic links.
But Rust can't express this pattern as is, so we were always
returning values but in `Option<T>` wrappers that the caller needed
to unwrap for the metadata.
(We really want an even more efficient API here that avoids the glib
objects entirely, e.g. no reason not to pass directly back a type
that lets Rust directly read from the fd for bare repos, but
that can come later)
Because the source is in a subdirectory, we lose out on cargo target
autodiscovery.
I noticed this when I edited one of the tests in a way that
should have failed, but didn't...
I want to write APIs that *require* the caller to have set up
an ostree transaction. It's natural to require passing a guard
to do so. But then we want an accessor for the repo.
