11:55 <FromGitter> <kingsleyh> hey anyone good with C/C++ I'm trying to create a binding but the the clang compiler is complaining: error: binding dereferenced null pointer to reference has undefined behavior [-Werror,-Wnull-dereference]

11:55 <FromGitter> <kingsleyh> with this:

11:55 <FromGitter> <kingsleyh> const T2& v2=*(const null_data_t*)(nullptr)

11:56 <FromGitter> <kingsleyh> ``````

12:34 <FromGitter> <naqvis> De-referencing null pointer indeed is an undefined behavior, so you are getting this error due to usage of (`-Wnull-dereference`) . Your above snippet of code is equivalent to `const T2& v2 = nullptr;`. Not sure why do you need to get a reference to *null pointer* ?

13:20 <FromGitter> <kingsleyh> @naqvis I see - it's not my code - I inherited it - looking for the best way to compile it

13:21 <FromGitter> <naqvis> good luck

18:02 <FromGitter> <azurelmao> Is it possible to get the current path of the executable?

18:06 <FromGitter> <Blacksmoke16> try https://crystal-lang.org/api/1.6.2/Process.html#executable_path%3AString%3F-class-method

18:49 <FromGitter> <azurelmao> Can I make this work? ⏎ ⏎ ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=639b6c2ca8211f623d84a4e3]

18:51 <FromGitter> <Blacksmoke16> within your custom read method, do `::File.read(...)`

18:51 <FromGitter> <Blacksmoke16> er well, i would suggest *not* doing this

18:51 <FromGitter> <Blacksmoke16> but instead just use `CrystalCave::File.read` instead of `File.read` versus monkey patching stuff into the stdlib type

18:53 <FromGitter> <azurelmao> well, the problem is that it still uses stdlib's File, but alright

18:53 <FromGitter> <moe:busyloop.net> yup, monkeypatching File seems like a bad idea unless you really have to. ⏎ (any shards that you import would then also use the monkey version)

18:54 <FromGitter> <azurelmao> oh

18:54 <FromGitter> <azurelmao> I thought only my executable would use it

18:54 <FromGitter> <Blacksmoke16> nope, its global

18:54 <FromGitter> <Blacksmoke16> granted if you dont have any dependencies, then it doesnt really matter but :shrug: still not a great practice when there are other just as good ways to do what you want

18:55 <FromGitter> <moe:busyloop.net> yup. it can be useful e.g. if you want to log all file access happening anywhere. ⏎ but changing the actual behaviour of such low-level stuff is a recipe for nasty surprises later.

18:58 <FromGitter> <azurelmao> not putting :: in front of the File in my custom method causes some really weird behaviour

18:58 <FromGitter> <azurelmao> ill remember that

18:59 <FromGitter> <Blacksmoke16> infinite loop?

18:59 <FromGitter> <azurelmao> im not sure, it messes with my whole system

18:59 <FromGitter> <azurelmao> like the audio im listening to gets glitched, apps close randomly

18:59 <FromGitter> <Blacksmoke16> its prob because without it its resolving to your `CrystalCave::File` type and not the stdlib

19:00 <FromGitter> <azurelmao> yeah that was prolly it but still really weird

19:00 <FromGitter> <Blacksmoke16> so its infinite loop using up memory and cpu

19:00 <FromGitter> <Blacksmoke16> until you cancel it or it crashes

19:01 <FromGitter> <azurelmao> is there nothing in the system which can prevent a malicious program from taking up all the memory?

19:03 <FromGitter> <Blacksmoke16> not that im aware of

19:04 <FromGitter> <Blacksmoke16> dont really have a way to know its malicious versus actually using it all versus a bug in the code

20:02 <FromGitter> <riffraff169> cgroups

20:03 <FromGitter> <riffraff169> at least in linux, and that is something done when you run the program, system management, not in the program itself

20:31 <FromGitter> <moe:busyloop.net> yup, by default these limits are carefully tuned to get in the way of normal usage as often as possible without preventing actual runaway-processes

20:32 <FromGitter> <moe:busyloop.net> god forbid you open more than 1024 fd's but yup, eating all memory and swapping the host to death, that's fine

20:56 <FromGitter> <RespiteSage> Yeah, I used to use Atom for development with a repo that had a very large number of files in its tree. Atom would gradually accumulate more and more memory as I used it until I couldn't use the OS well enough to kill it. I ended up running a service that would kill the process using the most memory if total memory usage was like 98%.

20:58 <FromGitter> <RespiteSage> So at least the OS I was using (OpenSUSE) didn't have any limits on process memory usage. I assume that's mostly the way it is, especially with Linux OSes.

22:42 <FromGitter> <jrei:matrix.org> By the way Kate now has native Crystal support, and is quite lean as an IDE

22:42 <FromGitter> <jrei:matrix.org> It uses 100MB for me