From: Hartmut Niemann <niemann@cip.e-technik.uni-erlangen.de>
  To  : ggi-develop@eskimo.com
  Date: Fri, 17 Jul 1998 16:50:44 +0200 (MESZ)

Re: GGI_AUTO

Marcus wrote:
> 
> 
> 0 is an absolute neccesity when we're dealing with graphtypes, as 
> graphtypes are made up of several bytes of info. If GGI_AUTO is
> -1 you can't do (GT_TRUECOLOR | GGI_AUTO) ...
Well, no. If you specify GT_TRUECOLOR, why specify GGI_AUTO too?

> 
> And having two different symbolic constants meaning the same
> thing is obviously already causing confusion, so GT_AUTO is
> a NO-NO.
Well, IMHO they don't. A wildcard pixel number and a wildcard graphtype
are two different things. What do you want to do if the graphtype
has to be expanded to 64 bits or on an architecture (win 3.x comes to mind)
where an int is still 16bit?
Or Alpha, where the graphtype still is an uint32 (*unsigned*, BTW), but
the visible.x and so on are integers, i.e. 64 bit values. 

... I had a closer look. ggi_mode.visible.x is an signed int16!

IMHO you try to mix oranges and spoons here ...

It looks like I am far more spoiled from Pascal, where different types
are different types, than you are :-)

> 
> That's why I still think GGI_AUTO == 0 is the ideal solution.
> Using the same "auto" value for ggiSetPalette() and all ggi_mode
> entries execpt the graphtype, instead of having the same for
> ggi_mode AND grapthtype and a different one for ggiSetPalette()
> is so bizzare I don't know what to say...
I don't want to be too stubborn about ggiSetPalette, where s=0 makes sense,
and where we can not use GGI_AUTO if it is nonnegative.

But please remember that graphtype==int is a typedef, not an absolute
truth, and one that could go away pretty quickly. I wouldn't want
to depend on that.

> 
> //Marcus
> 
> 
How can we solve that issue?

Hartmut

--  
Hartmut Niemann   --   niemann(a)cip.e-technik.uni-erlangen.de
http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi]