Le quartidi 24 brumaire, an CCXXV, Andreas Cadhalpun a écrit : > I suspect that having different sizes for the same struct in different > parts of the code base will upset some static analyzers.
Still, it is completely legal wrt the C standard. > Consider the (not so) theoretical case of API users simply (and wrongly) > using the structs on the stack instead of dynamically allocating them. > > With the internal pointer the internal struct gets allocated in the > respective init function and things mostly work fine, while with > your proposal this would cause out-of-bounds reads/writes, which > likely means an arbitrary code execution vulnerability. I think it will likely result in their application not working at all very soon, and therefore them realizing their mistake. This is exactly how I noticed that filfmts allocates the links itself. I would rather have found a way of making the structure unallocatable, but apparently the C standard refuses undefined structs even when it and the fields after it are not accessed. > If you really care so much about this, you can make the struct completely > private and add getter/setter functions for those elements that need > public access. I would be ok with that. But that is a big incompatible API change. I could argue that lavfi's API is currently unusable anyway. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
