-
Notifications
You must be signed in to change notification settings - Fork 187
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
Document and improve abstract reader/writer interface #208
base: dev
Are you sure you want to change the base?
Conversation
027704f
to
4f8c8df
Compare
4f8c8df
to
d2c2fd1
Compare
Forced commits to:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Stuart
Thank you for your patience. This is looking really good. I will not insist on coding style changes in the examples (they're your code) nor on the auto
usage. The reinterpret_cast
is a different case, please update that and please move the Doxygen docs to the .c sources (See https://www.doxygen.nl/manual/docblocks.html#structuralcommands).
I will accept the change without the getter-setter functions working on tokens and context. We can discuss which ones to have after this is merged. I'd rather have wrapper functions so the users don't need to know about the internals of the object, so we can later change them if necessary, like you're doing now.
Finally, what's WSHUB-458? Sounds like a JIRA task number. Can you add a link to the commit message body to what this is and remove from the first line?
Ahh, the
Good point, force of habit due to the fact I was doing this at work. I'll strip that token from the commit messages. |
d2c2fd1
to
5b74b5d
Compare
(oops, accidentally edited instead of quoting)
I'm using the Qt rules for |
Agreed, code clarity must be paramount. I do more C than C++ so not used to using C++ features like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's merge and let me see about using this in Qt too.
Gah, Travis hasn't run yet... Need to find someone to write GitHub Actions workflow, though likely that'll be me. |
Ahh |
Too bad. Thanks for the update. Let me do a manual check locally and then force the merging. |
96158b9
to
c356a31
Compare
So, last time we looked at this, we got caught out by Travis CI's shutdown. I've just done a rebase on the current |
c356a31
to
ec1ebfe
Compare
Second rebase to pick up the changes on |
Dependabot can provide automatic pull requests for things in the repository that should be updated. Example PR from dependabot against a repo owned by the github organization: github/opensource.guide#2248 Documentation: https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates
facilitate replacement of malloc/free functions open_memstream functions are left out of this change as they require other functions from stdlib.
We don't support this any more. ``` ../../src/cbor.h:255:69: error: '_Bool' is a C99 extension [-Werror,-Wc99-extensions] CBOR_INLINE_API CborError cbor_encode_boolean(CborEncoder *encoder, bool value) ^ ``` Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Homebrew no longer carries precompiled versions of Qt for macos-11, so switch to macos-13, the last on x86 CPUs (so we can still run Valgrind). It's also going away after the end of June. Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
``` ==21147== Valgrind: debuginfo reader: ensure_valid failed: ==21147== Valgrind: during call to ML_(img_get) ==21147== Valgrind: request for range [18446744069408125024, +16) exceeds ==21147== Valgrind: valid image size of 140733057859584 for image: ==21147== Valgrind: "/usr/local/Cellar/icu4c/74.2/lib/libicudata.74.2.dylib" ``` Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
I don't think we need to worry about Qt 4 any more. Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
Intel says this is needed Signed-off-by: Thiago Macieira <thiago.macieira@intel.com>
`cbor_parser_init` and `cbor_parser_init_reader` are substantially similar, however the latter misses clearing out `it->flags`, leaving it uninitialised so possibly unsafe. Rather than copying & pasting that from `cbor_parser_init`, lets just use one routine that does the "common" part, then each routine can focus on the specifics needed.
Describe the input parameters for the function and how they are used as best we understand from on-paper analysis of the C code.
The `token` parameter is not sufficient since it is effectively shared by all `CborValue` instances. Since `tinycbor` often uses a temporary `CborValue` context to perform some operation, we need to store our context inside that `CborValue` so that we don't pollute the global state of the reader.
In its place, put an arbitrary `void *` pointer for reader context. The reader needs to store some context information which is specific to the `CborParser` instance it is serving. Right now, `CborValue::source::token` serves this purpose, but the problem is that we also need a per-`CborValue` context and have nowhere to put it. Better to spend an extra pointer (4 bytes on 32-bit platforms) in the `CborParser` (which there'll be just one of), then to do it in the `CborValue` (which there may be several of) or to use a `CborReader` object that itself carries two pointers (`ops` and the context, thus we'd need an extra 3 pointers).
We simplify this reader in two ways: 1. we remove the `consumed` member of `struct Input`, and instead use the `CborValue`'s `source.token` member, which we treat as an unsigned integer offset into our `QByteArray`. 2. we replace the reader-specific `struct Input` with the `QByteArray` it was wrapping, since that's the only thing now contained in our `struct Input`. If a `CborValue` gets cloned, the pointer referred to by `source.token` similarly gets cloned, thus when we advance the pointer on the clone, it leaves the original alone, so computing the length of unknown-length entities in the CBOR document can be done safely.
What is not known, is what the significance is of `CborEncoderAppendType`. It basically tells the writer the nature of the data being written, but the default implementation ignores this and just blindly appends it no matter what. That raises the question of why it's important enough that the writer function needs to know about it.
This reads a CBOR file piece-wise, seeking backward and forward through the file if needed. Some seeking can be avoided by tuning the block size used in reads so that the read window shifts by smaller amounts.
Not 100% sure of the syntax for documenting struct-members outside of the struct as I'm too used to doing it inline, hopefully this works as expected. :-)
ec1ebfe
to
427e009
Compare
Okay, after picking up the changes in |
tinycbor
fork branchthiagomacieira/dev
adds support for abstract readers and writers, but the implementation had some limitations in cases where multipleCborValue
cursors were iterating over the same CBOR document, causing state contamination. The interface also was not documented.This documents the new interface and further builds upon it by slightly re-arranging
CborParser
members and opening thetoken
inCborValue
to use by the reader interface for any required purpose.This pull request is now re-based on
intel/dev
and supercedes thiagomacieira#2.