| 11:07 |
unpx |
signpost: hi there. Now checking what I have compiled |
| 11:13 |
unpx |
Okay, I didn't see that patch, ops. |
| 11:13 |
unpx |
smalpest-95K+nick+null |
| 11:13 |
unpx |
OpenBSD has this complain: ld: warning: knob.c(src/knob.o:(setval_str)): warning: strcpy() is almost always misused, please use strlcpy() |
| |
~ 25 minutes ~ |
| 11:38 |
signpost |
I added a cheap discard on my end for such malformed GetData requests also |
| 11:39 |
signpost |
The other one with a valid-looking hash is probably a genuine break in the chain we both can't fill. |
| 11:46 |
unpx |
jonsykkel: so in the end, one should keep track of string length when doing the parsing in parse_cmd, so other can strlcpy or strcmpci correctly I guess |
| 11:55 |
unpx |
Since I'm here, probably someone is interested in this https://codeberg.org/shufflecake/shufflecake-c |
| |
~ 52 minutes ~ |
| 12:47 |
signpost |
probs also worth mentioning that it's unexpected that unpx's "so in the end" message is seen by my node as a chain-break despite my being peered with unpx, curious if that's b00gly behavior of mine or expected behavior of current smalpest. |
| 12:48 |
signpost |
I should fart out another html chain walk to see wat the chain structure is |
| |
~ 1 hours 19 minutes ~ |
| 14:07 |
jonsykkel |
http://logs.nosuchlabs.com/log/pest/2026-06-11#1036152 << its indeed horibly coded but program cheks the strlen against k->max (bufer size minus 1) before the 2nd strcpy. k->def.s is "" in all cases for the 1st one (bufers are 33 and 221) |
| 14:09 |
jonsykkel |
http://logs.nosuchlabs.com/log/pest/2026-06-11#1036155 << ideally one should rewrite this pile of trash |
| 14:14 |
jonsykkel |
signpost heres wats in my db http://zzz.st/up/B9ul8LLs/ |
| 14:14 |
jonsykkel |
looks corect 2 me, u can chek it against urs |
| 14:21 |
signpost |
my client just considered your first message in this run a chain break too ^ |