[FFmpeg-devel] [PATCH] lavfi: get rid of FF_INTERNAL_FIELDS
Uoti Urpala
uoti.urpala at pp1.inet.fi
Sat Feb 4 13:09:36 EET 2023
On Fri, 2023-02-03 at 15:45 +0100, Nicolas George wrote:
> Andreas Rheinhardt (12023-02-01):
> > "One special guarantee is made in order to simplify the use of unions:
> > if a union contains several structures that share a common initial
> > sequence (see below), and if the union object currently contains one of
> > these structures, it is permitted to inspect the common initial part of
> > any of them anywhere that a declaration of the completed type of the
> > union is visible. Two structures share a common initial sequence if
> > corresponding members have compatible types (and, for bit-fields, the
> > same widths) for a sequence of one or more initial members."
> >
> > But there just is no union between the FF_INTERNAL_FIELDS
> > !defined(FF_INTERNAL_FIELDS) structures in the whole codebase.
>
> It is not necessary that there is one: it is enough that there could be
> one in another compilation unit, the code that handles these structures
> does not know what exists in the rest of the code base. This guarantee
> was made FOR unions, but it does not REQUIRE unions, it applies to
> anything that is semantically equivalent to a union.
This is not valid reasoning. Consider code such as
int f(struct s1 *p1, struct s2 *p2) {
p1->abc = 0;
p2->abc = 42;
return p1->abc;
}
where the field abc belongs to a shared initial sequence in s1 and s2.
If there is no common union visible when this code is compiled, it
seems valid for the compiler to hardcode this to return 0, even if it
may be called with p1 and p2 pointing to the same address. LTO may
generate the equivalent of this code when compiling a combination of
assignments and reads from files using different definitions for a
struct.
More information about the ffmpeg-devel
mailing list