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