sound issues

[frag.machine]

Thirdly, the behaviour of malloc differing between debug/release/compiler is a GOOD thing. Any memory bug you have is a memory bug. Generally involving breaking other bits of memory. Change some code somewhere and you get random differences elsewhere. Sure, okay, memory working the same way as debug builds always is easier, but results in minor errors that you'll never find. A malloc that is random every time is awesome.
Additionally, you can link your app against a third-party library that provides such debugging features instead of having to roll your own.

It depends. If the debug behaviour has tighter validation and constraints then yeah it's a good thing. If on the other hand you have a situation where debug malloc memsets 0 whereas release malloc doesn't, you've got a backdoor for subtle bugs to come in, and your debug build is effectively worthless for verifying correctness of your release build.

AFAIK this behavior is restrict to Microsoft's implementation and no other C runtime does this "automatic memset to 0 when malloc'ing" stuff in debug mode. Not to mention that it's both an useless performance penalty and a nasty way to induce novice (and even experienced) programmers in error.

[Spike]

msvc's debug malloc memsets to 0xcc (which is the x86 int3 debugging opcode).
Other compilers tend not to use different libraries for debug or release builds. You can force it though, or in linux, just use LD_PRELOAD.

With release builds, most secure operating systems will memset to 0 the first time you start it up. Well, less memset, more clear out for the sake of security. Of course, this only works the first time you use a page, rather than an actual allocation, as its the heap that is cleared, not the allocations. This means its quite likely you won't notice that its not cleared in a release build.

Anyway, point is, malloc > rewriting malloc, even if you wrap it. If you want cleared memory, use calloc instead.

[revelator]

yikes well as for strange stuff that can happen with bad memory pointers as i just found out the hard way.

command buffer goes boom literally last char of any command gets cut of example toggleconsole now fails with toggleconsol unknown command.
same for cvars.

keybindings also affected erf looks like i will have to redo the entire thing from scratch.

[revelator]

fixed the command crap now im left with the SZ_GetSpace errors

basically this happens whenever i try to load a map SZ_GetSpace 1 > max buffer size

well i dont quite get that one as the starting buffer is 256 bytes wide but an integer size of one is larger than it wtf

the only place i been able to hunt it down to is from some call to Msg_WriteByte the debugger stalls there however so bleargh.

might have to rewrite these functions to actually print the name of the function it failed in.

[revelator]

found the bugger maxclients was'nt initialized to zero.

works again now unfortunatly this had no affect on the sound problem whatsoever

may have to bite the sour apple and admit that something in my compiler is bitching loudly at this

[revelator]

changed the malloc calls that initialize to zero to calloc and works quite good.

still stuck on sound will try and look into an older darkplaces with migw support for anything i missed,

[revelator]

well its definatly compiler related as i just tried linking with the ms sdk libraries (works fine) but it still sounds like a frying pan with popcorn on it

i did notice a few warnings about variables allready defined elsewhere in my system headers the funny thing is these are not even included

one thing i came about thinking off was your quakeasm library i believe some of the sound system comes from this ?

allthough not sure i wonder if the ms compiled asm code somehow freaks out the gcc compiler hmm

[revelator]

well ill be damned and someone color me red it was indeed the quakeasm library after removing it and enabling the corresponding c functions the thing runs like hell on ice and sound works yay

[Chip]

Here's a C-newb question.

Can I use your compiler as a standalone solution for C-based programs? I'd be interested in building the Qoole source, the one that's freely available. What about C++?

[revelator]

it handles c/c++/ada/java so i would say yes

as for qoole not sure what compiler was used for it in the past but with some setup it should definatly be buildable with this.

[Chip]

it handles c/c++/ada/java so i would say yes

as for qoole not sure what compiler was used for it in the past but with some setup it should definatly be buildable with this.

I'll give it a shot and I'll let you know!

[revelator]

ill be happy to help as much as i can if any compatibility issues arise.

[Spike]

from what I remember, qoole was originally a dos program.

so this should be fun.
its already been ported once, so chances are it'll be the libraries used, rather than the code itself that present any issues.
may also need a makefile. *shudder*.

[revelator]

oh thats evil

i hope it dos'nt (phun phun) make calls to the 16 bit api else porting will be a bitch

[revelator]

just downloaded it to see if there would be any buggers i couldnt work around and hello and behold it uses mfc

it might be possible if you can link against the mssdk's mfc libraries but i suspect that wont be very easy.

tbh your better of with msvc in this case.