/tech/ - Technology

pic.png
[Hide] (367.5KB, 1920x1080)

Use bsearch() in these cases:
https://gitlab.com/fsirc/vmbot/-/blob/master/src/config.c#L123-154

The return value of malloc() doesn't seem to be checked anywhere, e.g. https://gitlab.com/fsirc/vmbot/-/blob/master/src/config.c#L23

You might want to rename src/config.h because C programmers commonly use a file with that filename as a dumping ground for macros defined by the build system.

You're hardcoding array lengths instead of using sizeof, you then strncpy() into these arrays with the hardcoded lengths. That's extremely hard to get right and you already got it wrong in multiple places, see my picture. The strncpy() dance is also much harder than just doing the work to get strlcpy() on systems that don't have it.

You don't check your config file's options for validity. Strings get truncated (extra bad for passwords) or they're "NULL if string is not a JSON string" as the Jansson documentation says. Integers just wrap around or you get a 0 when there's an error in the JSON.

I already found a bug in Jansson's API from reading its documentation: https://jansson.readthedocs.io/en/latest/apiref.html#c.json_integer_value
"Returns the associated value of integer, or 0 if json is not a JSON integer." Well then, it's impossible to check if an integer you got from that function was a valid "JSON integer" in every use case because 0 could be a valid value. Luckily, that's not the case when you're reading a port number from the config file. Reading the documentation further, it seems they have a better function called json_unpack_ex() that does communicate errors: https://jansson.readthedocs.io/en/latest/apiref.html#c.json_unpack_ex
It also seems to have a saner API, for instance you can ask it to read an int instead of that useless json_int_t type that should've been intmax_t.

Also, I try to simply boycott everything that uses JSON and XML instead because both formats are garbage, but if you're going to do that, you could at least use libexpat instead of libxml2 for XML. libexpat having an order of magnitude less lines of code than libxml2 is reason enough. If a project has say one bug every 1000 lines, then that's an order of magnitude less bugs. It's even part of the base system on OpenBSD which either means it sucks so much they forked it in which case it's too broken to use, or it's so good they use it in which case make that bug count in expat ten orders of magnitude less than libxml2 because libxml2 is made by GNOME, but I absolutely refuse to touch anything related to XML to find out. 

You could use libUCL instead of JSON for your config file, there's a sane configuration language hidden under all the useless features and dozens of different ways of doing the same thing in that library. Or just use YACC.

Your Makefile lacks an installation step and it can only make debug builds. True, the user could specify their own CFLAGS, but then they'll get a build failure because overriding CFLAGS also removes all the libraries the program links with. The user would have to read the Makefile to figure out how to fix it before using it, so that Makefile is about as good as not having one.
Make is braindamaged anyway, use Meson.

BTW, your program won't build on BSD because it assumes libraries and headers outside the base system are in the default search paths for the linker and compiler. It also won't build on any system that uses pkgsrc such as UnixWare 7 or OS X for the same reason. pkgconfig is the BSD and pkgsrc way of doing things (and it wasn't even created there) and it's available everywhere.

>if if if if if if

ifififif.webm
[Hide] (7.4MB, 1280x720, 00:25)

>>6777

>>6775
>The return value of malloc() doesn't seem to be checked anywhere, e.g. https://gitlab.com/fsirc/vmbot/-/blob/master/src/config.c#L23
Probably will fix, anyway, even if the chances of this returning NULL are extremely slim.
>You're hardcoding array lengths instead of using sizeof, you then strncpy() into these arrays with the hardcoded lengths. That's extremely hard to get right and you already got it wrong in multiple places, see my picture. The strncpy() dance is also much harder than just doing the work to get strlcpy() on systems that don't have it.
Yeah, good catch, will fix that for sure.
>You don't check your config file's options for validity. Strings get truncated (extra bad for passwords) or they're "NULL if string is not a JSON string" as the Jansson documentation says. Integers just wrap around or you get a 0 when there's an error in the JSON.
Yep, I was going to do that at some point, but didn't get around to it.

>>6771 (OP) 
Cool project! 

>https://gitlab.com/fsirc/vmbot
Just little nitpick... In files db.c and virt.c: can you use %d sprintf format specifier for unsigned values? I think you should replace them with %u.
Also, why does the libcutil makefile use cat and cp for installing instead of install(1)? Your libcutil also lacks a license (meaning it's proprietary software).

>>6780
>Also, why does the libcutil makefile use cat and cp for installing instead of install(1)
It's old code, I will fix that.
>Your libcutil also lacks a license (meaning it's proprietary software).
Yeah, missed that too since I was in a hurry to package it up.

>>6771 (OP) 
FUCK YEAH FREE COMPUTERS

>>6771 (OP) 
Is the bot still up? It isn't working on rizon.

>>6795
>>6793
No, I had some issues with libvirtd where it was hanging at random, and it's probably related to it being an older version. I will, though, try and get it back up under a new channel at a later date.

>>6804
>>6795
Bot is back up at #freespeech @ rizon. Nickname must be registered, of course.