[FFmpeg-soc] [soc] libavsequencer [PATCH 04/08] Track / pattern handling public API header file.

[Aurelien Jacobs]

On Sat, Aug 14, 2010 at 12:01:08AM +0200, Sebastian Vater wrote:
> Aurelien Jacobs a écrit :
> > On Fri, Aug 13, 2010 at 10:28:55PM +0200, Sebastian Vater wrote:
> >   
> >> Vitor Sessak a écrit :
> >>     
> >>> On 08/07/2010 09:46 PM, Sebastian Vater wrote:
> >>>       
> >>>> Vitor Sessak a écrit :
> >>>>         
> >>>>> On 07/13/2010 10:57 PM, Sebastian Vater wrote:
> >>>>>           
> >>>>>> Vitor Sessak a écrit :
> >>>>>>             
> >>>>>>> On 07/13/2010 09:35 PM, Sebastian Vater wrote:
> >>>>>>>               
> >>>>>>>> Vitor Sessak a écrit :
> >>>>>>>>                 
> >>>>>>>>> On 07/11/2010 10:07 PM, Sebastian Vater wrote:
> >>>>>>>>>                   
> >>>>>>>>>> typedef struct AVSequencerTrackData {
> >>>>>>>>>>                     
> >>> [...]
> >>>
> >>>       
> >>>> +/**
> >>>> + * Song track effect structure, This structure is actually for one row
> >>>> + * and therefore actually pointed as an array with the amount of
> >>>> + * rows of the whole track.
> >>>> + * New fields can be added to the end with minor version bumps.
> >>>> + * Removal, reordering and changes to existing fields require a major
> >>>> + * version bump.
> >>>> + */
> >>>> +typedef struct AVSequencerTrackEffect {
> >>>> +    /** Effect command byte.  */
> >>>> +    uint8_t command;
> >>>>         
> >>> enum...
> >>>       
> >> Again where's the problem? enums are all above.
> >>     
> >
> > The problem is that it seems you intended 'command' to be an enum, but
> > you declared it as an uint8_t instead.
> > You have to declare it as an enum to allow proper type checking (among
> > other things).
> > So for this one, what you want is:
> >     enum AVSequencerTrackEffectCommand command;
> >
> > The same apply to all the enum remarks that you didn't understood.
> >   
> 
> Ahh ok, thank you very much, I missed that point. But there are cases,
> where the enum types should be really uint8_t and uint16_t...how to
> solve that?

I really can't imagine any good reason why you would need to store
those struct fields as uint8_t or uint16_t...

Aurel