zdoom2.3.1 is broken on freebsd7.1 running on wine-1.1.18,1

[morbidtwatt]

soulpriestess smoke a blunt it will make you a fanboy of life!! Your taking internet way to serious, and enough about which os supports Brobdingnagian banana arms into our succulent chubby linda love lace because it has nothing to do with the main idea of this thread. Finally, I like to add that Chris is the first person to port zdoom to BSD with openal-soft. I would thank the minority for there luck, blessings and verbal vomit, but im not superstitious nor sympathetic to a cyberpunk. The true thanks go to Chris because im playing zdoom on bsd with openal

100% native now with zdoom on bsd yay im just a brontosaurus and zdoom is my tire tracked cockpit. Well now that all is said and done im going to bed and reporting for a full time bug hunt tomorrow.

[Graf Zahl]

Indeed - and therefore it's not a supported OS for ZDoom. I wish you luck getting it to work but this is clearly not the right forum for this thread.

Though I hope you would at least consider some of the needed changes? Those being...

Sure. Constructive help is always appreciated.

soulpriestess smoke a blunt it will make you a fanboy of life!! Your taking internet way to serious, and enough about which os supports Brobdingnagian banana arms into our succulent chubby linda love lace because it has nothing to do with the main idea of this thread. Finally, I like to add that Chris is the first person to port zdoom to BSD with openal-soft. I would thank the minority for there luck, blessings and verbal vomit, but im not superstitious nor sympathetic to a cyberpunk. The true thanks go to Chris because im playing zdoom on bsd with openal

100% native now with zdoom on bsd yay im just a brontosaurus and zdoom is my tire tracked cockpit. Well now that all is said and done im going to bed and reporting for a full time bug hunt tomorrow.

[/quote]

Final warning: Another such post and this thread is closed!

[Rachael]

morbidtwatt, it's nice to know that I've made such an impact on your internet experience, because like you said it's obviously serious business! Unfortunately, I don't have any blunts available to smoke, but from the sound of it you're not short on supply.

It's nice to see people like you acting your own intelligence level. You play the part well.

By the way, nice name. It's very fitting.

[Graf Zahl]

This is not the place for such a 'discussion' so I'm closing this thread now.

[randi]

These changes aren't BSD-specific, but are more for cleaning away older-styled code (malloc.h is deprecated, fmod.h shouldn't be included in non-fmod code, __va_copy is an internal function/replaced by va_copy in C99, kill() needs signal.h).

The manpages I read indicated you needed to include malloc.h to get malloc_usable_size. Is this no longer the case? Malloc.h is also listed as a required header for VC++. Is malloc.h really deprecated, or is FreeBSD overly critical?

I don't remember why I used __va_copy instead of va_copy, but I know there was a reason.

I'm unlocking this so you can respond if you like, but any posts by morbidtwatt will be deleted as soon as they're noticed.

[Chris]

These changes aren't BSD-specific, but are more for cleaning away older-styled code (malloc.h is deprecated, fmod.h shouldn't be included in non-fmod code, __va_copy is an internal function/replaced by va_copy in C99, kill() needs signal.h).

The manpages I read indicated you needed to include malloc.h to get malloc_usable_size. Is this no longer the case? Malloc.h is also listed as a required header for VC++. Is malloc.h really deprecated, or is FreeBSD overly critical?

Probably a bit of both. I don't know why a system would flat-out throw an error over using an old header instead of just a warning. My Linux manpages don't seem to have malloc_usable_size, although the page for malloc says stdlib.h.

However, it seems you're right. Including stdlib.h instead of malloc.h doesn't give malloc_usable_size. Interesting. http://www.slac.stanford.edu/comp/unix/ ... alloc.html says it's under stdlib.h, but it also says "`malloc_usable_size' is not portable." so I would expect some issues there regardless. I guess it would be best to leave m_alloc.cpp alone, then, until a CMake check is made to find which header it's in (can't say I'm in a hurry to do that).

I don't remember why I used __va_copy instead of va_copy, but I know there was a reason.

Perhaps because va_copy is C99, but MinGW was stuck at GCC 3.4 which didn't have it? That would be my guess, anyway. My man pages say:

Code: Select all

   va_copy()
       An obvious implementation would have a va_list be a pointer to the stack  frame  of
       the  variadic function.  In such a setup (by far the most common) there seems noth‐
       ing against an assignment

           va_list aq = ap;

       Unfortunately, there are also systems that make it an array of pointers (of  length
       1), and there one needs

           va_list aq;
           *aq = *ap;

       Finally,  on  systems  where arguments are passed in registers, it may be necessary
       for va_start() to allocate memory, store the arguments there, and also  an  indica‐
       tion  of  which  argument is next, so that va_arg() can step through the list.  Now
       va_end() can free the allocated memory again.  To accommodate this  situation,  C99
       adds a macro va_copy(), so that the above assignment can be replaced by

           va_list aq;
           va_copy(aq, ap);
           ...
           va_end(aq);

       Each  invocation  of  va_copy()  must  be  matched by a corresponding invocation of
       va_end() in the same function.  Some systems that  do  not  supply  va_copy()  have
       __va_copy instead, since that was the name used in the draft proposal.

CONFORMING TO
       The  va_start(),  va_arg(),  and  va_end()  macros conform to C89.  C99 defines the
       va_copy() macro.

[randi]

Perhaps because va_copy is C99, but MinGW was stuck at GCC 3.4 which didn't have it?

That would be a good guess, except x86-64 Linux is the architecture that actually needed va_copy as opposed to a normal assignment to get proper results, and I'm pretty sure I was using GCC 4 when I investigated that bug report, since I think ZDoom stopped compiling on GCC 3 sometime during the 1.23 series. I'm a bit surprised that GCC on FreeBSD wouldn't support __va_copy, since it's still GCC, and this function is defined in the GCC headers, not the libc headers.

[Chris]

That would be a good guess, except x86-64 Linux is the architecture that actually needed va_copy as opposed to a normal assignment to get proper results, and I'm pretty sure I was using GCC 4 when I investigated that bug report, since I think ZDoom stopped compiling on GCC 3 sometime during the 1.23 series.

Hmm. Well, C99 defines va_copy as a macro, and GCC makes __va_copy a macro, too. So something like this would work:

Code: Select all

#if defined(va_copy)
va_copy(aq,ap);
#elif defined(__va_copy)
__va_copy(aq,ap);
#else
aq = ap;
#endif

Both va_copy and __va_copy should be identical, though.

BTW, I noticed in DCanvas::ParseDrawTextureTags, va_end(tags) doesn't get called (possibly leaking memory/resources) if either of these are hit:

Code: Select all

        if (img == NULL || img->UseType == FTexture::TEX_Null)
        {
                return false;
        }

        // Do some sanity checks on the coordinates.
        if (x < -16383 || x > 16383 || y < -16383 || y > 16383)
        {
                return false;
        }

[randi]

BTW, I noticed in DCanvas::ParseDrawTextureTags, va_end(tags) doesn't get called (possibly leaking memory/resources) if either of these are hit:

Thanks for finding that.