Should Dlls always return a value?

Sammi3

Member
I wasted perhaps almost half a day trying to debug my dll crashing (I even built a tool during that time that can compile GameMaker projects from the terminal so that I could run my game from vscode so that I could attach a debugger to see what was happening in the dll). The return value in GameMaker was set as a string but the dll actually didn't return anything it was void. All my other Dll methods were voids and hadn't caused any problems but I noticed that there were some methods that had crashed before but with a couple of changes, that was alleviated.

I decided to change the return value of the dll to double just to see if GameMaker needed to clear it's mind and voila, the function didn't crash anymore. This left me more confused so I decided to return it to a string and it started crashing again.

Now, I just want to know if the issue was that GameMaker is always expecting a return value and that it might cause something like a segmentation fault if I don't.
 

FrostyCat

Redemption Seeker
It's expecting a return value in both cases, but with strings there is an added attempt to dereference the returned value as a pointer. If you return void, there may be junk in the return, and dereferencing that causes a segmentation fault crash. The junk would be the same for a double return value, but it's crash free because there is no added attempt to dereference.
 

Sammi3

Member
Makes sense. I was being really naive there. Of course GM would try to dereference. Alright, so it would be safe to mark it as double? I already use a buffer to return values in more specific types so I don't really want to return a value for the sake of it and I'd really like to keep my c++ code as readable as possible whilst making sense.

Or would it be better to just return a value of completion of the code like when you return a value from main to signify exit codes?
 

FrostyCat

Redemption Seeker
It should be safe for now, as long as you don't use the return value. But you can't guarantee that if the extension will be used by a public audience. So returning a status value just in case would be the best course of action.

If you want to keep it "readable" and safe, you can always do a "fake void" macro that really just means double. That has its downsides (i.e. confusing a real void with the fake one), but that's the price you pay for worshipping "readability".
 

Sammi3

Member
It should be safe for now, as long as you don't use the return value. But you can't guarantee that if the extension will be used by a public audience. So returning a status value just in case would be the best course of action.

If you want to keep it "readable" and safe, you can always do a "fake void" macro that really just means double. That has its downsides (i.e. confusing a real void with the fake one), but that's the price you pay for worshipping "readability".
Thanks for all the help! Although I do intend for many people to use this dll, I'll leave it at void. I have an abstraction layer over the dll calls that the user is intended to use that sort all that stuff out anyway (especially since there's a lot of buffer work going on under the hood). I do love worshipping my "readability" (P.S why are we putting it in quotation marks? ;) )
 
Top