On Tue, 2009-12-08 at 08:33 -0800, Younes Manton wrote:
> On Tue, Dec 8, 2009 at 9:55 AM, michal <mic...@vmware.com> wrote:
> > This branch simplifies pipe/p_format.h by making enum pipe_format what
> > it should have been -- an enum.
> >
> > As a result there is no extra information encoded in it and one needs to
> > use auxiliary/util/u_format.h to get that info instead. Linking to the
> > auxiliary/util lib is necessary.
> >
> > Please review and if you can test if it doesn't break your setup, I will
> > appreciate it.
> >
> > I would like to hear from r300 and nouveau guys, as those drivers were
> > using some internal macros and I weren't 100% sure I got the conversion
> > right.
> >
> > Thanks!
> 
> The Nouveau stuff that you touched looks correct to me.
> 
> Any particular reason why the enums are explicitly numbered? I'd let
> the compiler do the numbering for us unless there's a reason not to.
> (Or is the intention here that future additions only happen at the
> tail and we therefore implicitly threaten anyone considering otherwise
> with the prospect of tediously updating all the entries that follow?
> :) )

:) It's as you suspected in parenthesis -- to ensure that names<->values
mapping won't change, new values are added to the bottom, and old values
leave a hole.

Jose


------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to