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 <michae...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
