Re: [AD] PALETTE and RGB*

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2002-07-24, Eric <ebotcazou@xxxxxxxxxx> wrote:
> > Can someone explain why some functions take "RGB *" arguments instead of
> > "PALETTE" arguments (eg. load_bitmap compared with get_palette).  AFAICT
> > they mean the same thing to a compiler, but PALETTE is easier to read (a
> > full palette is expected, rather than a single RGB entry).
> 
> Probably because the load_* and save_* functions don't always require a
> PALETTE argument in practice. For example, src/bmp.c:load_bmp() starts with:
> 
>    if (!pal)
>       pal = tmppal;
> 
> Using NULL avoids cluttering the stack with an useless array.

Although it's array syntax, it's still a pointer getting passed.
You can pass NULL either way.

> But I agree this "feature" doesn't improve the consistency of the API.
> 
> > Unless there is reason not to, I'm going to apply the following patch.
> 
> I'm ok with the API changes if you document that NULL is an "acceptable"
> PALETTE. Or maybe add a NO_PALETTE identifier.

Hmm, I didn't realise that load_bitmap didn't say anything about passing
NULL already.  Obviously that should be added.

> However I'm not so fond of the internal changes: why to hide the real
> type of the argument behind a typedef ? The same story exists for
> struct BITMAP vs BITMAP.

Consistency?  Readability?

> > I think it is source compatible, and most likely binary compatible.
> 
> Even for C++ ?

Should be source compatible (seems to be).  I have no idea about the
binary compatibility.  C++ gurus?

-- 
王浩禎