-
Notifications
You must be signed in to change notification settings - Fork 18
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
Preparation for v1.0 – Peer Review #33
Comments
Took a quick first look at everything except for all the C code (mostly the build system):
I didn't yet look into fixing most of them. Feel free to tell me what I should propose patches for. Edit: To fix diff --git a/Makefile.am b/Makefile.am
index cb0163a..bd9fe30 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,7 +14,9 @@ ChangeLog:
dist-hook: ChangeLog INSTALL
-EXTRA_DIST = autogen.sh xcb-xrm.pc.in include/xrm.h
+EXTRA_DIST = autogen.sh xcb-xrm.pc.in include/xcb_xrm.h include/database.h
+EXTRA_DIST += include/entry.h include/externals.h include/match.h
+EXTRA_DIST += include/resource.h include/util.h
lib_LTLIBRARIES = libxcb-xrm.la
You can now produce release tarballs with |
Thanks for all the findings :) Some comments:
If you want to send a patch, I'll be happy to merge it. It's only necessary when running tests, though, not for building the library, so I think it's rather low priority.
Is there something "bad" about
Weird. I always check for this. Must've forgotten recently… :)
I've tried splitting the test suite into multiple source files before (and one file for the utility functions) and failed miserably. If you can send a PR that at least does the infrastructure change for this, I'd love to split the different tests.
Any application using the header file can't use those, though. They'd have to include the actual source file, no? Those aren't static because a) other files and b) the tests use them. I'm not sure how I'd fix this. I thought making them non-static but not defining them in the library's header file would be the right way.
Awesome, thanks! I'll apply that patch. Of course feel free to send PRs if you want the commit to be in your name. :) |
Nope & ok. I marked the checkbox.
Ok. I checked which of those functions is actually used by the tests. That's just two of them. All the other ones you can just rename to something else (they are exported because of |
Thanks for the information. I'll rename those to |
That'd make them even more part of the API and ABI of the library. ;-) Edit: Personally, I'd rather leave this the way with the two remaining functions being exported, but not declared in a header (if no alternative shows up). |
OK. I'll see if I can easily rewrite the tests then and if not we'll leave it for now. |
Some comments on the API:
@@ -202,7 +213,7 @@ void xcb_xrm_database_free(xcb_xrm_database_t *database);
* components as the resource name.
* @param resource A pointer to a xcb_xrm_resource_t* which will be modified to
* contain the matched resource. Note that this resource must be free'd by the
- * caller.
+ * caller via a call to @ref xcb_xrm_resource_free ().
* @return 0 on success, a negative error code otherwise.
*/
int xcb_xrm_resource_get(xcb_xrm_database_t *database, const char *res_name, const char *res_class, Other random comments will follow (likely as pull requests, if I finally find the time). My "notes" are at https://gist.github.com/psychon/73344f301e8b6947f0512374e978c771. |
Thanks @psychon, I appreciate all the feedback. Keep it coming. :) I've made some of the changes. Some comments / questions:
The behavior is described here, too: https://tronche.com/gui/x/xlib/appendix/d/XGetDefault.html I'll open a separate issue for this and check it off in this list for now.
No, I don't think so. We say we handle spec-conform entries and the spec (https://tronche.com/gui/x/xlib/resource-manager/file-syntax.html) contains
For one: because it's easier that way. :) However, the Xlib equivalent
I left it to be integers on purpose to have freedom in the future to define error codes (which they currently aren't), so this is forwards thinking. As long as we don't define codes, no one can (or should) rely on them. If in the future we want to return specific codes and define them, we can change the actual return value in a compatible way. I don't know if it'll ever happen, but if it does, I don't want to break the API. Does that make sense? And some comments to your notes gist:
I thought I had a comment on there. Anywho. Yes. This and the other place are… not ideal. We should fix this, I guess. I'll open a bug.
Was this intentional?
No, it isn't :) The function can in fact allocate the entry and return an error. Or at least used to, maybe it changed. Either way, the
I thought about it, but ultimately, those things are both semantically and syntactically so closely related that they'd end up sharing most of the code anyway. Edit: I think I just now realized what you meant. Yeah, I guess that could be done.
This would exit the application again due to a bug in the library, no? I'll also incorporate some of the changes mentioned in that gist right now. |
@psychon One more thing, is it actually safe to change the string returned by |
Yes, I don't see Xlib handling any kind of globbing. (Only checked the source code, didn't check all that carefully.
Yes it is. The first and second All following returns are via Well, ok. It's not a double free. It's dead code that's not necessary and that can actually cause a crash if
My thought here was to have some parser working similar to I hope that the resulting code would be easier to understand. Right now I mostly just skipped the code in
I actually don't have any problem with that. "allocation error" (and other runtime errors) is not a bug in the library and shouldn't exit anything. I can life better with "this should never happen"-kind of asserts. Ultimately, it's your call what to do here.
That's a good question. Looking at the man page of |
Maybe so, but I'd argue that this is a nice improvement over Xlib. Technically it leads to different behavior because files might be loaded that weren't loaded before, but… I mean… you know.
OK, convinced. :) It used to be necessary then, because I remember adding it for a reason. Things have changed since, I guess.
Yeah, I see your point. It's probably better to provoke seeing such a bug if we introduce it later on.
I've changed it and at least the tests seem happy about it (including valgrind). |
Nice work overall! Some thoughts:
|
@stapelberg Thanks!
Rewriting my answer this from scratch for the third time now :-) I think maybe the best way is to remove the converter functions again and change all That should cover all cases: I can ignore the return value and rely on the provided output argument if I don't want to provide my own fallback, but if I do care, I check the return value and ignore the output parameter. Summarizing your thoughts it sounds like that's pretty much what you were saying, right?
No, so far I've only run |
Still no time to code / send PRs. However, I ran some code coverage analysis and besides error handling (which is mostly out-of-memory-handling and hard to test), For testing file reading, adding
My ToDo-Diff shrunk to https://gist.github.com/psychon/ce61abbab5039b8b99667b24f3fe93fa. Thanks for handling some of it already! |
Yeah, I haven't written tests for those yet because it's hard to do so. I do test them manually a lot, including valgrind runs, but that's not very satisfying. The hint with
This is what the specification says: "The file name is interpreted relative to the directory of the file in which the line occurs (for example, if the file name contains no directory or contains a relative directory specification)."
No, thank you for all the feedback, support and reviewing. :) I've taken care of the Edit: Now also took care of the double free and provided a PR for not destroying the source database when merging. |
I have opened tickets for all remaining issues AFAICT, that should be easier to keep an overview. I've put the milestone on those that I think should be fixed for v1.0. |
Alright. Everything has been taken care of AFAICT. Time for v1.0! |
This issue serves as a sync point for a review by anyone who wants to review. Please add any comment here and/or create issues for it. Please also note when you are done with the review.
The idea of this is to have this new library reviewed before a first stable release to avoid breakage.
The text was updated successfully, but these errors were encountered: