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

[Michael Niedermayer]

On Fri, Feb 06, 2015 at 11:20:03AM +0100, Stefano Sabatini wrote:
> On date Thursday 2015-02-05 23:03:56 +0100, Michael Niedermayer encoded:
> > On Thu, Feb 05, 2015 at 12:10:12PM +0100, Stefano Sabatini wrote:
> > > On date Wednesday 2015-02-04 16:10:03 +0100, Michael Niedermayer encoded:
> [...]
> > > > > 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?
> > 
> > gcc on some embeded platforms seems to use types smaller than int
> > when it can by default. You can get the same behavior with
> > -fshort-enums on x86 if you like to try,
> > 
> > gcc on linux x86  will also use int64_t if a enum constant is too
> > large for 32bit idependant of the short enum flag
> > 
> > 
> > > 
> > > 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.
> > 
> > 6.7.2.2 Enumeration specifiers
> > ...
> > 4 Each enumerated type shall be compatible with char, a signed integer type, or an
> >   unsigned integer type. The choice of type is implementation-defined,110) but shall be
> >   capable of representing the values of all the members of the enumeration. The
> >   enumerated type is incomplete until after the } that terminates the list of enumerator
> >   declarations.
> 
> Thanks for taking the time for elaborating this reply. I'm fine with
> the patch.
> 

> Still better would be to extend av_opt() code as you suggested. Also
> documenting this shouldn't be bad

actually we dont need any changes to av_opt, just a value would need
to be added to each affected enum
this would work because above quote says that enum must be compatible
to a integer type and by adding a appropriately sized value we force
this type to int (or larger) and comparible types may alias each
other so accesing it via an int pointer is safe in that case


    7 An object shall have its stored value accessed only by an lvalue expression that has one of
    the following types:76)
    # a type compatible with the effective type of the object,
    # a qualified version of a type compatible with the effective type of the object,
    # a type that is the signed or unsigned type corresponding to the effective type of the
        object,
    # a type that is the signed or unsigned type corresponding to a qualified version of the
        effective type of the object,
    # an aggregate or union type that includes one of the aforementioned types among its
        members (including, recursively, a member of a subaggregate or contained union), or
    # a character type.



> (and I guess we have a lot of places
> where we use enums in options, right?).

yes, there are a few more

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150206/d94442a8/attachment.asc>