options/m_config_frontend: don't allow recursive profile inclusion

[kasper93]

It is easy to craft a config file that loads a profile recursively. To prevent this, not only check the depth of the current inclusion but also ignore already-seen profile names.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[Dudemanguy]

It is easy to craft a config file that loads a profile recursively.

I thought this was a feature? It looks like this commit just avoids duplicate profile names though or am I misunderstanding it.

[kasper93]

It is easy to craft a config file that loads a profile recursively.

I thought this was a feature? It looks like this commit just avoids duplicate profile names though or am I misunderstanding it.

After this patch mpv will not load already loaded profiles. I see no reason why we should allow recursive profiles load.

Consider this example config:

profile=e
[e]
profile=e
profile=e

[Dudemanguy]

There's references to recursive profiles in the Conditional auto profiles section in the manual though. I mean I really don't mind either way but the change, if any, should be noted.

[Dudemanguy]

Just for the the public record, I was misled by the wording in the manual. It's not really recursive. It's just that you can refer to another profile in the profile-cond. The PR has no effect and we can always update the language in the docs later.

[kasper93]

Profiles are loaded recursively, this commit guards that we don't try to load already seen ones which would result in infinite recursion. And the current limit on include depth is not guarding against that fully as shown with example before.