ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<dimenus>
oooo an llvm crash when using opengl
<dimenus>
oh wow, it's codeview causing the crash
<dimenus>
interesting
cenomla has quit [Quit: cenomla]
<andrewrk>
dimenus, I believe the codeview llvm code is young and they are interested in bug reports
<andrewrk>
or just make the allocator mandatory and call it a day
<dimenus>
do we have default arguments in zig?
<andrewrk>
we do not
<andrewrk>
the recommended way to do default arguments is to have similarly named functions, where one of them has all the args, and the other one dispatches to the first one with the default argument
<dimenus>
having a nullable type basically does what i want anyway I think
<andrewrk>
zig's idea about allocators is that, yes, it's more annoying to write code when you have to think about them. but ultimately the code will be reusable in more environments, and when reading code, the fact that a given piece of code depends on memory allocation is helpful to know
<andrewrk>
we want someone to call std.loadLibrary or whatever, and see the API, and think WTF why do I need an allocator? and then they learn, yes, we have to allocate memory just to put a stupid null byte at the end
<andrewrk>
also to decode-reencode unicode
<dimenus>
lol
<dimenus>
yeah not hiding the allocator does make the most sense and i ultimately agree with it
jfo has joined #zig
arBmind has joined #zig
arBmind1 has quit [Ping timeout: 240 seconds]
jfo has quit [Ping timeout: 260 seconds]
jfo has joined #zig
jfo has quit [Ping timeout: 248 seconds]
jfo has joined #zig
<dimenus>
andrewrk, i'm starting to like the feel of errors in zig
<dimenus>
oops, tops hould be HMODULE not HINSTANCE
<dimenus>
same type though
<andrewrk>
hm yeah this looks good
<andrewrk>
I think the problem is unrelated to @OpaqueType()
<andrewrk>
if you still suspect it, you can use a debugger and make sure we are doing a function call giving the same pointer address to FreeLibraryA that we got from windowsLoadDll
<dimenus>
i coudln't get it to work with c_void or just a straight int either (HMODULE is a struct typedef with just an int inside)
<andrewrk>
do we need CoInitializeEx or something like that?
<dimenus>
no, COM isn't needed in this case
<dimenus>
i'm going to run a debug build in a second and take a look
<andrewrk>
were you able to call a function from the DLL?
<dimenus>
didn't test that yet
jfo has quit [Ping timeout: 258 seconds]
<andrewrk>
I suspect that might not also be working
ofelas has joined #zig
ofelas has quit [Remote host closed the connection]
<dimenus>
hah, i'm just an idiot
<dimenus>
the symbol is FreeLibrary not FreeLibraryA
<dimenus>
debugging in VS caught it instantly
<dimenus>
wonder why it linked successfully though....
<dimenus>
oooh that might be a bug
<dimenus>
llvm generated a kernel32.lib with a symbol that says its FreeLibraryA even though that symbol doesn't exist in the real kernel32.lib
<dimenus>
i wonder if by being an idiot I found an llvm bug
<andrewrk>
hmm very interesting
<andrewrk>
ha, I found an llvm bug by being an idiot last night working on unions
<andrewrk>
hm we should be able to make it a better error message if someone mistypes a DLL function name
<dimenus>
the problem is lld links the lib successfully
<dimenus>
soooo we no idea it was a problem
<andrewrk>
that makes sense, because we want to be able to cross-compile a .exe without having access to the .dll
<andrewrk>
but we should detect if we're compiling natively
<andrewrk>
and then try to validate the lib calls
jfo has joined #zig
arBmind has quit [Quit: Leaving.]
<dimenus>
We can call GetProcAddress at compile time to validate that the entries in the def file are all accurate
<andrewrk>
good idea
<andrewrk>
LoadLibrary gives the DLL we call ability to crash the program. So we would have to spawn a child process to do the LoadLibrary and GetProcAddress
<andrewrk>
and if we're going to spawn a child process, we can write that child process in zig :)
<dimenus>
that isn't a bug in llvm btw, it's just how import libs work
<dimenus>
I didn't realize there wasn't any magic to them
ofelas has joined #zig
arBmind has joined #zig
<andrewrk>
agreed
<andrewrk>
yeah they're surprisingly simple
<andrewrk>
makes you want to work on hot code swapping, eh?
<dimenus>
i did that without knowing what i was doing on my game originally
<dimenus>
a la casey muratori
<dimenus>
LARGE MEMORY LEAKS
<dimenus>
i wish we could add an attribute to c datatypes to make them coercible into zig datatypes
<dimenus>
so with a c function that returns a BOOL i can do
<dimenus>
if(returnedGood())
<andrewrk>
a BOOL is an integer, it's not actually true or false
<andrewrk>
so the best way to handle this would be a function like this
<dimenus>
i know but from a zig perspective, we define what BOOL is
<dimenus>
if we define it as a c_int but that it's capable of being a bool