Page 1 of 1

Libgba: gba_compression.h doesn't have const source pointer

Posted: Fri Sep 30, 2011 6:20 am
by Dwedit
I was just looking through gba_compression.h, and I noticed that none of the system calls declared the "source" pointer as const. They are just plain void* pointers.
Also, the Vram functions should probably indicate that the destination pointer is a unsigned short pointer.

Code: Select all

//---------------------------------------------------------------------------------
// Decompression functions
//---------------------------------------------------------------------------------
void BitUnPack(void  *source, void *dest, BUP* bup);
void LZ77UnCompWram(void *source, void *dest);
void LZ77UnCompVram(void *source, void *dest);
void HuffUnComp(void *source, void *dest);
void RLUnCompWram(void *source, void *dest);
void RLUnCompVram(void *source, void *dest);
void Diff8bitUnFilterWram(void *source, void *dest);
void Diff8bitUnFilterVram(void *source, void *dest);
void Diff16bitUnFilter(void *source, void *dest);

Re: Libgba: gba_compression.h doesn't have const source poin

Posted: Fri Sep 30, 2011 5:21 pm
by mtheall
This doesn't really matter because all these functions do is set up some parameters that get handled by the hardware. If it made a difference they would have been made different a long time ago.

If you're looking at semantics, void* (arbitrary pointer) is the best choice because even though VRAM is typically written as 16-bit writes, the underlying data structure can be 4-bit or 8-bit as well.

Re: Libgba: gba_compression.h doesn't have const source poin

Posted: Fri Sep 30, 2011 6:54 pm
by Dwedit
I'm used to getting compiler errors when you try to promote a const u32* to a plain u32*. Is this a non-standard extension of GCC that a const pointer can be promoted to a non-const void pointer, or is it perfectly legal?
I do get warnings when it happens.

Re: Libgba: gba_compression.h doesn't have const source poin

Posted: Sat Oct 01, 2011 1:49 pm
by WinterMute
Ok, so I'm wrong, not all of your posts are hugely offensive ...

In my experience not all casts from const to non const are errors. Are you using C++ or just -Werror?

libgba was mostly written a long, long time ago when I was still feeling my way around C and figuring out how my assembly language experience fitted into writing a lot of C code. Many things are awkward and/or just wrong and not many people used libgba - mostly people used their own headers or libtonc or some other random set of headers they found on the internet.

The source pointers should probably be const - I'd have to go through and check the code but I'm pretty sure that none of these functions modify the source. Having a specific pointer size on the destination is a little more awkward, 32bit is as valid as 16bit and using one of those specifically can make it awkward to use the other.

The best way to get this fixed is to submit a patch, I'm more than happy to accept changing the source pointer on these functions to const. Changing the size of the destination needs a bit more thought and a few examples of code which suffers from using a void pointer.

The patch tracker is at http://sourceforge.net/tracker/?atid=66 ... unc=browse - all patches should be in the form of a unified diff against SVN HEAD.