James Almer (12023-04-29):
> History has shown that these notifications have had no effect on users, and
> even on this same project's developers. A good example was ffserver.c, which
> accessed an unholy amount of lavf private fields (both exposed in public
> headers and even internal ones), and first_dts from AVStream, which was not
> only accessed by prominent library users (One of which refuses to do things
> right and forces distros to use a patch to expose said field on their ffmpeg
> packages for the sake of supporting their application, thus making a pure
> recompilation from our tree no longer a drop-in solution on anyone's
> system), but also by ffmpeg.c, with no developer noticing it to prevent such
> code being pushed.

Since we are discussing types for the fftools, not librairies, what
people outside the project might do is not an issue

As for abuse of fields private to a part of the code by another part of
the code, I think you are somewhat rewriting history here.

The reason the fftools used to access private fields of the libraries is
not that developers neglected the rules against using them, it is that
no such rule existed when the code was written, they came later.

But if you really think we need to enforce the rule, then there still
are better solutions than using a separate structure and littering the
code with casts.

For example we can apply __attribute__((unavailable)) to the private
fields except in the part of the code where they are allowed.

(The attribute might not be supported on all compilers, but it is plenty
enough that it is supported on the compilers used by the FATE instances
that test submitted patches and the compilers used by some of us.)

This is a MUCH better solution than what is proposed here.

Regards,

-- 
  Nicolas George