00:27 <+bridge> [ddnet] <Ryozuki> @heinrich5991 @Learath2 https://stackoverflow.com/questions/7825055/what-does-the-operator-do-in-c
00:30 <+bridge> [ddnet] <Ryozuki> we need to use trigraphs, to be inclusive of people with ancient keyboards
00:30 <+bridge> [ddnet] <Ryozuki> :BASED:
00:30 <+bridge> [ddnet] <Voxel> ??!??! SPOILERS ??!??!
00:31 <+bridge> [ddnet] <Voxel> ??!??!SPOILERS??!??!
05:50 <+bridge> [ddnet] <Jupstar ✪> I hope you did some benchmarks
05:51 <+bridge> [ddnet] <Jupstar ✪> Else we can't compare
08:03 <+bridge> [ddnet] <Ryozuki> I didnt xd
08:37 <+bridge> [ddnet] <Ryozuki> another day on nixos
08:39 <+bridge> [ddnet] <Ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1027470179384438804/unknown.png
08:58 <+bridge> [ddnet] <chillerdragon> Wat nix can do
08:59 <+bridge> [ddnet] <chillerdragon> Sounds niche
09:05 <+bridge> [ddnet] <Ryozuki> Google it
09:23 <+bridge> [ddnet] <Ryozuki> ```c
09:23 <+bridge> [ddnet] <Ryozuki> //  Are you there god??/
09:23 <+bridge> [ddnet] <Ryozuki> ??=define _(please, help)
09:23 <+bridge> [ddnet] <Ryozuki> ??=define _____(i,m, v,e,r,y) r%:%:m
09:23 <+bridge> [ddnet] <Ryozuki> ??=define ____ _____(a,f,r,a,i,d)
09:23 <+bridge> [ddnet] <Ryozuki> main(__)<%____(!_(-~-??-((-~-??-!__<<-
09:23 <+bridge> [ddnet] <Ryozuki> ??-!!__)<<-??-(!!__<<!!__))+-~-~-??--~-~
09:23 <+bridge> [ddnet] <Ryozuki> -~-~-~-~-??-(-~-~-~-~-??-!!__<<-~!!__),-
09:23 <+bridge> [ddnet] <Ryozuki> ??-!__))<%??>%>_(__,___)??<____
09:23 <+bridge> [ddnet] <Ryozuki> (printf("please let me die??/r%d bottle%s"
09:23 <+bridge> [ddnet] <Ryozuki> " of bee%s""""??/n",(!(___
09:23 <+bridge> [ddnet] <Ryozuki> %-~-~!!___))?--__+!___++:__+!___++,!(__-!!___)
09:24 <+bridge> [ddnet] <Ryozuki> &&___%-~-~!!___??!??!!(___%-~-~!!___??!??!__
09:24 <+bridge> [ddnet] <Ryozuki> -(-~!!___))?"":"s",___%-~-??-!!___<-??-!!___?
09:24 <+bridge> [ddnet] <Ryozuki> "r on the wall":"eeeeeeer! Take one down,pass ??/
09:24 <+bridge> [ddnet] <Ryozuki> it around")&&__&&_(__,___),"mercy I'm in pain")??<??>??>
09:24 <+bridge> [ddnet] <Ryozuki> ```
09:24 <+bridge> [ddnet] <Ryozuki> valid c
09:24 <+bridge> [ddnet] <Ryozuki> gcc -w --trigraphs
09:25 <+bridge> [ddnet] <Voxel> try explaining this entire section to someone 200 years ago
09:33 <+bridge> [ddnet] <Ryozuki> > Tolerance for weird errors
09:33 <+bridge> [ddnet] <Ryozuki> > 
09:33 <+bridge> [ddnet] <Ryozuki> > Note if you're going into more weird languages, you'll run into types of errors you almost certainly won't hit in the popular ones.
09:33 <+bridge> [ddnet] <Ryozuki> > 
09:33 <+bridge> [ddnet] <Ryozuki> > You'll get opaque error messages, especially if the language has invariants that aren't common in other environments (Rust's ownership checker is probably the most common example of "no analogue in a more common language," but this can also mean Mercury's determinism checks, or Pony's "reference guarantees"). To be clear: these parts are exactly why learning a new language is fun! This is what it costs to reap the reward of Perlis langaug
09:33 <+bridge> [ddnet] <Ryozuki> https://morepablo.com/2022/09/so-you-re-using-a-weird-language.html
13:10 <+bridge> [ddnet] <Patiga> @Not Keks do you happen to know what the max amount of images is for maps?
13:11 <+bridge> [ddnet] <Patiga> I created one with too many and now it uses other textures from the game when it tries to display some of them
13:35 <+bridge> [ddnet] <Jupstar ✪> 64
13:36 <+bridge> [ddnet] <Jupstar ✪> But i actually thought ddnet clamps
13:36 <+bridge> [ddnet] <Jupstar ✪> And not randomly access out of bounds
13:38 <+bridge> [ddnet] <Jupstar ✪> Well it clamps loading in mapimages.cpp
13:39 <+bridge> [ddnet] <Jupstar ✪> Maybe not at runtime dunno
13:40 <+bridge> [ddnet] <Jupstar ✪> Tbh the map should not even load if it's so buggy
13:40 <+bridge> [ddnet] <Patiga> huh I thought 64 was an arbitrary limit by the editor
13:40 <+bridge> [ddnet] <Jupstar ✪> Even if we clamp it will show wrong results
13:40 <+bridge> [ddnet] <Jupstar ✪> Sadly no
13:40 <+bridge> [ddnet] <Jupstar ✪> Vanilla
13:41 <+bridge> [ddnet] <Patiga> ow
13:41 <+bridge> [ddnet] <Patiga> I just created a script to turn images/gifs/videos into menu backgrounds, but haven't found a suitable video file that is <= 2 seconds yet
13:42 <+bridge> [ddnet] <Patiga> hm, then I should probably also introduce that 64 limit in twmap
13:44 <+bridge> [ddnet] <Jupstar ✪> U could do texture atlas
13:45 <+bridge> [ddnet] <Jupstar ✪> 8k should be supported by almost anything
13:45 <+bridge> [ddnet] <Patiga> hm true
13:46 <+bridge> [ddnet] <Patiga> that sounds like a big hassle though, I think I'll just stay with the limitation and drop remaining frames
13:47 <+bridge> [ddnet] <Patiga> didn't want to create complicated logic, only automate the current process
13:47 <+bridge> [ddnet] <Patiga> https://cdn.discordapp.com/attachments/293493549758939136/1027547652553965599/2022-10-06_13-33-26.mkv
13:47 <+bridge> [ddnet] <Patiga> aww mkv doesn't get embedded
13:48 <+bridge> [ddnet] <Patiga> depending where I was in the menu a different texture was shown instead of the too many frames
13:48 <+bridge> [ddnet] <Patiga> this one showed me that those are indeed other game textures ^^
13:48 <+bridge> [ddnet] <murpi> change the file extension to mp4 and it'll embed
13:49 <+bridge> [ddnet] <Patiga> fineee :p
13:49 <+bridge> [ddnet] <Patiga> https://cdn.discordapp.com/attachments/293493549758939136/1027548222580871168/mp4.mp4
13:50 <+bridge> [ddnet] <Jupstar ✪> We can must increase the limit for ddnet but check it in map realease tool
13:50 <+bridge> [ddnet] <Jupstar ✪> Just*
13:51 <+bridge> [ddnet] <Jupstar ✪> But yeah auto correction must is fine too
13:51 <+bridge> [ddnet] <Patiga> I mean my use case here isn't really something that should be accommodated to explicitly
13:51 <+bridge> [ddnet] <Patiga> but yeah I'll add the check I guess
13:52 <+bridge> [ddnet] <Jupstar ✪> Mhh 64 images are 260 mb
13:52 <+bridge> [ddnet] <Jupstar ✪> Guess 256 should work out xd
13:52 <+bridge> [ddnet] <Jupstar ✪> Ah actually double bcs mipmap
13:53 <+bridge> [ddnet] <Jupstar ✪> So 128
13:53 <+bridge> [ddnet] <Patiga> 64 should already be 512MB i think
13:53 <+bridge> [ddnet] <Patiga> > 1920 * 1080 * 4 * 64 / 1024 / 1024
13:53 <+bridge> [ddnet] <Patiga> > 506.25
13:54 <+bridge> [ddnet] <Patiga> it adds up quite quickly 😅
13:55 <+bridge> [ddnet] <Jupstar ✪> Yeah mipmap
13:55 <+bridge> [ddnet] <Jupstar ✪> So x2 for u
13:55 <+bridge> [ddnet] <Patiga> so 64 -> 1 GB
13:56 <+bridge> [ddnet] <Jupstar ✪> Maybe lower framerate
13:56 <+bridge> [ddnet] <Jupstar ✪> Yes if you want fullhd res true
13:56 <+bridge> [ddnet] <Patiga> ah true
15:13 <+bridge> [ddnet] <Mr.Gh0s7> I just found this networking guide/rescourse https://www.gabrielgambetta.com/client-server-game-architecture.html. It's well written if anyone wants to check it out
15:15 <+bridge> [ddnet] <Mr.Gh0s7> It's for fast-paced multiplayer
15:19 <+bridge> [ddnet] <Mr.Gh0s7> It also has a cool demo showing the effect of lag, client predictions, reeconciliation, and interpolation https://www.gabrielgambetta.com/client-side-prediction-live-demo.html
16:32 <+bridge> [ddnet] <Tater> it doesn't include any equivalent for anti-ping but for an FPS it's not needed because of lag compensation
16:34 <+bridge> [ddnet] <Tater> it would be cool to do server side rollback or "lag compensation" in teeworlds. I tried to make it once but saving and loading world states is not as easy on the server as it is on the client right now
16:34 <+bridge> [ddnet] <Tater> it would be cool to do server side rollback or "lag compensation" in teeworlds/ddnet. I tried to make it once but saving and loading world states is not as easy on the server as it is on the client right now
16:36 <+bridge> [ddnet] <Tater> I guess it's probably unreasonable for an FPS client to run a full physics simulation on the client like we do
16:37 <+bridge> [ddnet] <TsFreddie> server rollback probably doesn't really work that well with entity projecties
16:37 <+bridge> [ddnet] <Tater> how come?
16:37 <+bridge> [ddnet] <TsFreddie> even our hooks isn't instant hit like lots of completive FPS do
16:38 <+bridge> [ddnet] <Tater> ah I should have prefaced that the serverside rollback in ddnet would only be for preventing lag spikes. if you tried to sync the players and the server then it would be a nightmare yes
16:39 <+bridge> [ddnet] <Tater> ah I should have prefaced that the serverside rollback in ddnet would only be for preventing lag spikes. if you tried to sync the players and the server in real time then it would be a nightmare yes
16:39 <+bridge> [ddnet] <TsFreddie> i'm talking more about bullets projectiles
16:39 <+bridge> [ddnet] <Mr.Gh0s7> Why wouldn't server rollback work for entity projectiles though?
16:39 <+bridge> [ddnet] <TsFreddie> well, server rollback implies that it favors client views, so it tries to match what client sees when dealing with bullet collision. that might make the party taking damage see bullet hitting them that looks like missed.
16:41 <+bridge> [ddnet] <Mr.Gh0s7> Wouldn't the same concept of applying lag compensation apply to rollback projectiles?
16:41 <+bridge> [ddnet] <TsFreddie> i think lag compensation and collider rollback are the same thing.
16:42 <+bridge> [ddnet] <TsFreddie> maybe there are other server rollbacks that i don't know :justatest:
16:42 <+bridge> [ddnet] <TsFreddie> if you want to deal with lag spikes then usually what people do is just to accept client states instead of only inputs. but that also introduces complexity in physics and cheat detection.
16:42 <+bridge> [ddnet] <Tater> the idea is that you only do rollback on the server if you were missing client inputs from past ticks (it would actually be always but just for implication) then when a client lags and drops inputs if the client also sends their past inputs on every tick then the server can go back and re-simulate with their inputs that it didn't have before. This is kinda what overwatch does
16:42 <+bridge> [ddnet] <TsFreddie> oh i see
16:42 <+bridge> [ddnet] <Tater> the idea is that you only do rollback on the server if you were missing client inputs from past ticks (it would actually be always but just for simplification) then when a client lags and drops inputs if the client also sends their past inputs on every tick then the server can go back and re-simulate with their inputs that it didn't have before. This is kinda what overwatch does
16:43 <+bridge> [ddnet] <TsFreddie> but in that case i think most game would just increase the play ahead on the client-side and call it a day.
16:44 <+bridge> [ddnet] <Tater> yes but that's not acceptable for ddnet xd
16:44 <+bridge> [ddnet] <TsFreddie> :kek:
16:44 <+bridge> [ddnet] <TsFreddie> ye
16:44 <+bridge> [ddnet] <Tater> also you can still do that
16:44 <+bridge> [ddnet] <Tater> you can use both
16:45 <+bridge> [ddnet] <TsFreddie> definitely should fix the O(n^2) physics before doing anything rollback tho.
16:45 <+bridge> [ddnet] <Tater> I mean the client seems fine with it
16:45 <+bridge> [ddnet] <Tater> it runs the san O(n^2) physics up to 200 times every tick I think
16:45 <+bridge> [ddnet] <Tater> maybe its not the same physics?
16:46 <+bridge> [ddnet] <Tater> it runs the same O(n^2) physics up to 200 times every tick I think
16:46 <+bridge> [ddnet] <TsFreddie> i mean server cpu are usually weaker.
16:46 <+bridge> [ddnet] <Tater> I suppose
16:46 <+bridge> [ddnet] <Tater> even 2 ticks of rollback is already a 4x improvement in "play ahead" buffer over current ddnet
16:47 <+bridge> [ddnet] <Tater> under normal conditions
16:48 <+bridge> [ddnet] <Tater> I have not profiled a server with many players so idk if the physics are actually the most expensive part
16:49 <+bridge> [ddnet] <Tater> probably is I guess
16:49 <+bridge> [ddnet] <TsFreddie> and maybe snapping as well?
16:50 <+bridge> [ddnet] <Tater> dunno xd
16:55 <+bridge> [ddnet] <Tater> idk how most physics optimizations work but I guess the issue is that it's hard to determine if it's impossible for 1 tee to interact with another tee since with tunes and all sorts of things you basically can never rule it out. it's much harder than just rigid body collisions
16:56 <+bridge> [ddnet] <Tater> maybe it is possible but you would have to be quite careful in before skipping some physics
16:57 <+bridge> [ddnet] <Tater> maybe it is possible but you would have to be quite careful before skipping some physics
16:57 <+bridge> [ddnet] <TsFreddie> :justatest: i mean you can probably assume the tuning wouldn't be so ridiculous like zooming across the screen and collide with a tee on the other side of the map within one tick
16:59 <+bridge> [ddnet] <Tater> idk I haven't looked closely at which parts are O(n^2) and which are not
16:59 <+bridge> [ddnet] <Tater> I assume projectiles are just O(n) ?
16:59 <+bridge> [ddnet] <TsFreddie> n is all entities, which includes character and projectiles and pickups
16:59 <+bridge> [ddnet] <TsFreddie> a simple quadtree could be a huge improvement already.
16:59 <+bridge> [ddnet] <Tater> ah true
17:00 <+bridge> [ddnet] <Patiga> > i mean you can probably assume the tuning wouldn't be so ridiculous like zooming across the screen and collide with a tee on the other side of the map within one tick
17:00 <+bridge> [ddnet] <Patiga> meanwhile sg bug, giving infinite speed upwards :happy:
17:01 <+bridge> [ddnet] <TsFreddie> :justatest:  no sure which bug is that, and are we keeping that kind of speed as features as well
17:01 <+bridge> [ddnet] <Patiga> yea, its when you are at the exact same position as the other tee (inside of each other), and shoot sg
17:01 <+bridge> [ddnet] <Tater> I thought we have to keep all features xd
17:01 <+bridge> [ddnet] <TsFreddie> i see
17:02 <+bridge> [ddnet] <Patiga> division by 0 and so on
17:02 <+bridge> [ddnet] <TsFreddie> there are too many "features" to keep track of
17:02 <+bridge> [ddnet] <Tater> yeah that's a large part of the issue I thing
17:02 <+bridge> [ddnet] <Tater> everyone afraid to touch physics
17:02 <+bridge> [ddnet] <TsFreddie> i mean does div by 0 even has the same behavior in different compilers
17:02 <+bridge> [ddnet] <Tater> also no tests
17:02 <+bridge> [ddnet] <Tater> yeah that's a large part of the issue I think
17:03 <+bridge> [ddnet] <Patiga> yea its undefined I think. it was discussed a few days ago that it was still not replaced with explicit behavior
17:03 <+bridge> [ddnet] <TsFreddie> i couldn't see we keeping a feature that might behave differently in the future or on different hardware lol
17:03 <+bridge> [ddnet] <Patiga> oh wait its probably not undefined, no? float math is pretty well defined iirc
17:04 <+bridge> [ddnet] <TsFreddie> i have no diea
17:04 <+bridge> [ddnet] <TsFreddie> i have no idea
17:04 <+bridge> [ddnet] <TsFreddie> :kek: sounds like we are just gonna if that one and assign it to Infinity or something.
17:04 <+bridge> [ddnet] <Patiga> ah, its defined by the ieee standard but its not enforced in the c++ standard according to https://stackoverflow.com/questions/42926763/the-behaviour-of-floating-point-division-by-zero
17:05 <+bridge> [ddnet] <Tater> it should be easy to keep that bug since it only happens when both tees are at exactly the same position, so it's easy to check
17:05 <+bridge> [ddnet] <TsFreddie> ye, but I don't really think we should keep it tho.
17:05 <+bridge> [ddnet] <TsFreddie> maybe as a map bug compatibility or something.
17:06 <+bridge> [ddnet] <Tater> idk, making any change to the physics will be controversial
17:07 <+bridge> [ddnet] <Tater> but if the sg bug prevents doing a more optimized physics then I think there will be many other things that also prevent it
17:07 <+bridge> [ddnet] <Ryozuki> Iirc div by 0 is ub
17:07 <+bridge> [ddnet] <Ryozuki> In c++
17:42 <+bridge> [ddnet] <gerdoe> it needs to refactor everything as i got it
17:42 <+bridge> [ddnet] <gerdoe> i tried to integrate quadtree buut...
17:42 <+bridge> [ddnet] <gerdoe> nothing is done right it seems
18:02 <+bridge> [ddnet] <Izanagi> it would be nice if there was a small number above the friend heart that says how many friends are in this one server
18:02 <+bridge> [ddnet] <Izanagi> https://cdn.discordapp.com/attachments/293493549758939136/1027611699823521832/unknown.png
18:03 <+bridge> [ddnet] <Tater> that's a really good idea
18:03 <+bridge> [ddnet] <Learath2> Why bother optimizing physics unless we are allowing higher player counts? We have enough headroom per tick to do whatever we want, unless it becomes too tight I really wouldn't bother with it
18:03 <+bridge> [ddnet] <Learath2> Nice idea, could you open an issue on github for it?
18:03 <+bridge> [ddnet] <Learath2> If not I'll try not to forget to create one after this lecture
18:04 <+bridge> [ddnet] <Izanagi> ok i'll do
18:12 <+bridge> [ddnet] <Izanagi> i find this notice is not nicely positioned, at least in german idk how it is with english, maybe find a better place for it
18:12 <+bridge> [ddnet] <Izanagi> https://cdn.discordapp.com/attachments/293493549758939136/1027614434568450079/unknown.png
18:13 <+bridge> [ddnet] <Alexander> suggestion: when people are voting for a map change - maybe the server could /save your progress (if possible) if the map change vote goes through so you dont lose progress
18:14 <+bridge> [ddnet] <Izanagi> or just make the propotions better with margins idk
18:14 <+bridge> [ddnet] <Izanagi> or just make the proportions better with margins idk
18:39 <+bridge> [ddnet] <deen> Thanks @Lukamane ^
18:51 <+bridge> [ddnet] <Jupstar ✪> @Patiga where is the tool? 😄
19:38 <+bridge> [ddnet] <Ryozuki> i think nixos is better suited for servers
19:38 <+bridge> [ddnet] <Ryozuki> actually its like a glorified docker xd
19:38 <+bridge> [ddnet] <Ryozuki> ill switch to gentoo without systemd
19:41 <+bridge> [ddnet] <Ryozuki> ill buy a 64gb usb3.2 and install this https://github.com/ventoy/Ventoy
19:41 <+bridge> [ddnet] <Ryozuki> so i dont need to bother again
19:45 <+bridge> [ddnet] <Ryozuki> anyone know smth better than this <https://www.amazon.es/Memoria-SanDisk-Extreme-velocidades-Lectura/dp/B01MU8TZRV>
19:45 <+bridge> [ddnet] <Ryozuki> but at this price range
19:50 <+bridge> [ddnet] <Learath2> ```Indirect leak of 5447 byte(s) in 13 object(s) allocated from:
19:50 <+bridge> [ddnet] <Learath2>     #0 0x7f1467217817 in __interceptor_malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libasan.so.6+0xb2817)
19:50 <+bridge> [ddnet] <Learath2>     #1 0x7f1444275ff7  (<unknown module>)```
19:51 <+bridge> [ddnet] <Learath2> I get these bizarre leaks, it smells like they are in external libraries, but why do they end up being from unknown_module?
20:50 <+bridge> [ddnet] <Learath2> Ok, if ever you get stumped by the output of ASan or LSan, `report_objects=1` for LSan and `fast_unwind_on_malloc=0` on ASan options helps a lot
20:52 <+bridge> [ddnet] <Learath2> (maybe that's how we should run it on CI too? it is slower, but it'll give stack traces that are actually useful in some cases)
20:56 <+bridge> [ddnet] <Learath2> I call every cleanup function properly and curl still leaks, maybe rust people were right, there are no good C libraries
21:11 <+bridge> [ddnet] <Learath2> Ok, actually I do cleanup properly, leak sanitizer just runs too early, hm
21:16 <+bridge> [ddnet] <Learath2> Why on gods green earth is leak sanitizer running before all global destructors happen?
21:20 <+bridge> [ddnet] <Jupstar ✪> why do u rely on exit time destructors
21:26 <+bridge> [ddnet] <Ryozuki> good good
21:26 <+bridge> [ddnet] <Jupstar ✪> lmao, maybe read 1 sentence later 😄
21:27 <+bridge> [ddnet] <Ryozuki> no need
21:27 <+bridge> [ddnet] <Ryozuki> :BASED:
21:27 <+bridge> [ddnet] <Jupstar ✪> just use valgrind
21:28 <+bridge> [ddnet] <Jupstar ✪> it also shows uninitialized values without needing an own compiled memsanitizer compatible os xd
21:29 <+bridge> [ddnet] <Jupstar ✪> @Ryozuki if u create a thread, do you also destroy it manually? or do you think it's better to leave it to the OS?
21:30 <+bridge> [ddnet] <Ryozuki> i mean a thread is destroyed by joining it
21:30 <+bridge> [ddnet] <Ryozuki> maybe with a timeout of 0 xd
21:30 <+bridge> [ddnet] <Jupstar ✪> yeah i mean a co thread u use the whole time
21:30 <+bridge> [ddnet] <Learath2> It's bizarre, it does do the leak check after the destructor, but it reports things that are guaranteed to be freed after the destructor as still leaks
21:30 <+bridge> [ddnet] <Ryozuki> i use a signal for that usually or smth
21:31 <+bridge> [ddnet] <Jupstar ✪> question is would a perfect OS, also trust its software so much that it doesn't care
21:31 <+bridge> [ddnet] <Mr.Gh0s7> Kinda off-topic what's teewolds connection sceme? What protocols are used?
21:31 <+bridge> [ddnet] <Jupstar ✪> need to make the perfect OS
21:31 <+bridge> [ddnet] <Jupstar ✪> UDP
21:31 <+bridge> [ddnet] <Jupstar ✪> no "real" connection as in tcp
21:32 <+bridge> [ddnet] <Jupstar ✪> basically own connection logic
21:32 <+bridge> [ddnet] <Learath2> We do a handshake and establish some sort of reliable transport on top of UDP, but yeah, it's not tcp
21:32 <+bridge> [ddnet] <Mr.Gh0s7> Ok thanks
21:34 <+bridge> [ddnet] <Ryozuki> @Not Keks https://agourlay.github.io/brute-forcing-protected-zip-rust/
21:34 <+bridge> [ddnet] <Ryozuki> i found this blog post some days ago
21:34 <+bridge> [ddnet] <Ryozuki> he uses threading
21:35 <+bridge> [ddnet] <Ryozuki> and no, he doesnt guess the password its not about that
21:45 <+bridge> [ddnet] <Learath2> Ok, I'm out of ideas and bored at this point
21:46 <+bridge> [ddnet] <Learath2> I allocate the exact same place I call curl_global_init and free where I call curl_global_cleanup, my allocation is not detected as expected, but stuff allocated by curl through global_init and freed in global_cleanup get detected as leaks