[FFmpeg-devel] [PATCH 1/7] ffprobe: Change string_validation to int, its accessed via AVOption as int

[Stefano Sabatini]

On date Wednesday 2015-02-04 16:10:03 +0100, Michael Niedermayer encoded:
> On Wed, Feb 04, 2015 at 03:23:59PM +0100, Michael Niedermayer wrote:
> > On Wed, Feb 04, 2015 at 12:34:53PM +0100, Stefano Sabatini wrote:
> > > On date Monday 2015-02-02 23:22:09 +0100, Michael Niedermayer encoded:
> > > > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > > > ---
> > > >  ffprobe.c |    2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/ffprobe.c b/ffprobe.c
> > > > index d352bb6b..30f9cba 100644
> > > > --- a/ffprobe.c
> > > > +++ b/ffprobe.c
> > > > @@ -338,7 +338,7 @@ struct WriterContext {
> > > >      unsigned int nb_section_frame;  ///< number of the frame  section in case we are in "packets_and_frames" section
> > > >      unsigned int nb_section_packet_frame; ///< nb_section_packet or nb_section_frame according if is_packets_and_frames
> > > >  
> > > > -    StringValidation string_validation;
> > > > +    int string_validation;
> > > >      char *string_validation_replacement;
> > > >      unsigned int string_validation_utf8_flags;
> > > >  };
> > > 
> > > What's the problem with the enum and av_opt()?
> > > 
> > > Enums help with debugging.
> > 

> > the enum might be a different data type than int, it might have
> > a different sizeof() than sizeof(int), av_opt accessing it could
> > fail.

Is it a theoretical difference or does it affect some
platform/compiler? In that case, could be a defect in the
platform/compiler?

>From my reading of the C spec, enums and int should be treated in the
same way by the compiler, but I'm probably wrong.

> > Iam not aware of a real platform where this actually happens but that
> > could be my lack of knowledge of how enums are defined in the various
> > ABIs
> 
> If people prefer to keep using enums for the fields then it should be
> possible to avoid this problem also by introducing a dummy value
> in the affected enums which is too large for uint16 but fits in int32
> this would force the enum to use int as data type.
> This might require accesses in AVOption to use AV_R/WN32 to avoid
> theoretical strict aliassing issues
> also it leaves the even more theoretical issue that a platform could
> use int64_t as enum type or some more weird in between type
-- 
FFmpeg = Free & Formidable Muttering Prodigious Erratic Glue