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 (and I guess we have a lot of places where we use enums in options, right?). -- FFmpeg = Funny and Fundamental Mere Plastic Evil God _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
