IRC Logs for #crux-devel Monday, 2019-03-04

*** xor29ah has quit IRC00:21
*** xor29ah has joined #crux-devel00:21
ryuojaeger: guess what? i discovered an inefficiency in pkgadd.00:26
ryuothe way it handles the rules for what to do with certain file paths...00:27
ryuoit recompiles the RE every time it needs to search for a match.00:27
ryuothis is a performance killer.00:27
ryuoit's possible to reuse the compiled engine, so it makes more sense to store the engine if you are going to use it repeatedly.00:27
*** xor29ah has quit IRC00:29
*** xor29ah has joined #crux-devel00:30
jaegermakes sense00:33
*** xor29ah has quit IRC00:39
*** xor29ah has joined #crux-devel00:39
ryuojaeger: /var/lib/pkg/rejected is a directory pkgadd uses to unpack all files to that aren't mean to overwrite something?00:56
jaegerfiles that are configured not to be overwritten in pkgadd.conf00:59
jaegerand for rejmerge to find00:59
ryuoso it basically seems to reroute them here.00:59
ryuoso /var/lib/pkg/rejected/etc/foo00:59
ryuowould have been rejected from /etc/foo00:59
ryuothere we go.01:03
ryuoadded some comments and decided to add one of my favorite hacks.01:03
ryuousing a union to combine a set of fields of the same type with an array.01:04
ryuoit allows you to iterate over them with ease.01:04
jaegeruploaded another test ISO to
ryuojaeger: great.03:58
ryuo i just been working on designing this library.03:58
ryuofeel free to look at the source. i'm throwing in some of clones of macros i use a lot.03:59
jaegerI'll give it a look tomorrow. Got some other non-crux stuff to do03:59
ryuoindeed. later.04:00
jaegertake care04:00
ryuoi don't expect to get far quickly, but i'll work on this.04:00
ryuojaeger: i'd appreciate feedback as i implement it. you know pkgutils better than I do i'm sure.04:00
ryuoi intend to use C99 and C11 features as they're useful.04:01
*** xor29ah has quit IRC14:53
*** xor29ah has joined #crux-devel14:56
*** onodera has joined #crux-devel19:38
*** onodera has quit IRC19:49
*** onodera has joined #crux-devel19:50
jaegerryuo: <-- something like that for the mallocs?22:53
ryuojaeger: yes, but you don't need to use the RV of strncpy. it just returns the first argument.22:59
ryuobut let's see here...22:59
ryuoeo - so... + 122:59
ryuoassuming zero indexed...23:00
ryuook. the length checks out.23:00
ryuoassuming the eo is one after the actual last character23:00
ryuoYep it is.23:01
ryuoThe relative rm_eo element indicates the end offset of the match, which is the23:01
ryuo       offset of the first character after the matching text.23:01
*** onodera has quit IRC23:01
ryuojaeger: though for this case, i'd suggest memcpy since you know the length.23:02
ryuoof both.23:02
ryuomemcpy works as long as both buffers contain at least n bytes. it doesn't care about the null terminator.23:03
jaegerI wondered why strncpy returns a pointer but hadn't put much thought into it23:03
ryuobut hm. still wouldn't save the need to manually write it.23:03
jaegeryeah, seemed like 6 of 1, half a dozen of the other to me23:03
ryuojaeger: just read the man pages. it's the best way to understand how libc C functions work.23:03
jaegeryeah, I did23:03
ryuojust pay attention. some have minor details that change things greatly.23:04
jaegerchar *strncpy(char *dest, const char *src, size_t n); <-- notice that it returns a char *23:04
ryuolike the man page of strtol documents how its odd error checking works.23:04
jaegerI know using it isn't required23:04
ryuofair enough.23:04
ryuostrtol can't signal an error through its arguments or RV.23:05
ryuoit writes to errno, but you have to set it to 0 first to know if strtol changed it.23:05
jaegersame thing with snprintf... for some reason I didn't use any return from those23:05
jaegereven though it has one23:05
ryuosnprintf's RV only is useful for indicating truncation or an error.23:05
jaegerbut did use it for strncpy. chalk it up to inexperience, I suppose23:05
ryuobut realistically the only error i can see snprintf having is truncation related.23:06
ryuosome strings are capped anyway by the implementation so truncation is irrelevant in those cases23:06
ryuoe.g., path names23:06
ryuojaeger: indeed, but you could also have just used strndup.23:07
jaegerall good. I'm not spending time on it right now, just needed a break from package building crap at work23:07
ryuoindeed. good stuff.23:07
ryuoi used to stumble in C a lot before I understand that I had to manage the storage behind a pointer myself.23:08
ryuostack is the most convenient allocation method for regular use... it's fastest way to allocate temporary memory, but it's limited in size.23:09
ryuo~8MB is the default size.23:10
jaegerI enjoy the memory management as a mental exercise23:10
jaegerI think I did it correctly with the structs, just not with the strings23:10
ryuoi see. i just advise using stack if you need a scratch pad so to speak and don't need a large allocation.23:11
ryuoi usually will use it to format strings and copy the final result with strdup or strndup23:11
ryuoincidently if you rely on asprintf, it can be duplicated with snprintf functionality on unsupported platforms.23:12
ryuosnprintf has a mode that returns how much space is actually needed, so you can just run it once to get an allocation size, and run it again to format the actual string.23:13

Generated by 2.14.0 by Marius Gedminas - find it at!