Re: [AD] PALETTE and RGB*

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> 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.

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. 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.

> I think it is source compatible, and most likely binary compatible.

Even for C++ ?

--
Eric Botcazou