On Fri, May 19, 2006, Marcel Siegert wrote:
> Trent Piepho wrote:
> >enum dvbfe_interleaver {
> > DVBFE_INTERLEAVER_IGNORE = (0 << 0),
> > DVBFE_INTERLEAVER_NATIVE = (1 << 31),
> > DVBFE_INTERLEAVER_INDEPTH = (1 << 30),
> > DVBFE_INTERLEAVER_AUTO = (1 << 29)
> >};
> >
> >Now the DUMMY value isn't needed. One less symbol is defined, and there is
> >no issuse with warnings on switch statements. No one needs to look at the
> >value of DVBFE_INTERLEAVER_NATIVE, so who will care that it is now (1<<31)
> >instead of (1<<0)?
>
> the dummy value is needed to keep struct sizes on different architectures.
> e.g. arm
> the << 31 guarantees that an unsigned int 32 bit wide will be used as the
> underlaying
> internal integer representation type.
>
> my 0.02$:
> and as, from my knowledge, counting starts at 0 in a computer
> environment/programming language
> normally. so your idea is practicable to avoid a value, but non standard in
> normal coding
> logic. that even may confuse people more than having a specialised dummy
> value.
In my version of the patch I only added DUMMY values to those
enums which didn't have any other "natural" value for 1 << 31
(AUTO was normally assigned 1 << 31).
BTW, on variable-sized-enums architectures the problem
is only that a future API extension must not cause the
size of an enum to change (because this would break binary
compatibility). Maybe I got carries away and added a
DUMMY in a place where an extension can never happen...
Johannes
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
