various: upgrade option flags to uint64_t #15457

guidocella · 2024-12-08T12:17:35Z

UPDATE_CLIPBOARD currently has the same value as M_OPT_DEFAULT_NAN, so increment all constants after UPDATE_OPT_LAST. But increment them by 5 so we can add a few more UPDATE flags without either forgetting to increase them like in e1d30c4, or having to increase them each time like in a5937ac.

options/m_option.h

kasper93 · 2024-12-08T13:42:29Z

options/m_option.h


 // Like M_OPT_TYPE_OPTIONAL_PARAM.
-#define M_OPT_OPTIONAL_PARAM    (1 << 30)
+#define M_OPT_OPTIONAL_PARAM    (UINT64_C(1) << 63)


Could we start from 63 and count down? So we can add new flags here instead of before NAN one.

So NAN would be 64, ALLOW_NO, would be 62 and so on.

And after last flag we can add static_assert(UPDATE_OPT_LAST < M_OPT_OPTIONAL_PARAM), so it is easily visible requirement.

github-actions · 2024-12-08T14:08:40Z

Download the artifacts for this pull request:

Windows

macOS

na-na-hi · 2024-12-08T16:34:59Z

options/m_option.h

+    // type time: string "no" maps to MP_NOPTS_VALUE (if unset, NOPTS is
+    // rejected) and parsing: "--no-opt" is parsed as "--opt=no"
+    M_OPT_DEFAULT_NAN      = (1 << 5),
+    M_OPT_ALLOW_NO         = (1 << 6),


Forgot the comment for M_OPT_ALLOW_NO.

na-na-hi · 2024-12-08T16:35:46Z

options/m_option.h

+    UPDATE_IMGPAR          = (1 << 14), // video image params overrides
+    UPDATE_INPUT           = (1 << 15), // mostly --input-* options
+    UPDATE_AUDIO           = (1 << 16), // --audio-channels etc.
+    UPDATE_PRIORITY        = (1 << 17), // --priority (1Windows-only)


1Windows-only

na-na-hi · 2024-12-08T16:43:12Z

options/m_option.h

-#define UPDATE_OPT_LAST         (1 << 26)
-
-// All bits between _FIRST and _LAST (inclusive)
+enum option_flags {


I think this shouldn't use enum here. I consider a value of enum type can only be one of the defined exact value instead of some OR'd values.

If you want to group flags you can add a comment at the beginning of this section like the "These flags are used to describe special parser capabilities or behavior." for the next section below.

It was kasper's preference to use enum. I think it's more readable without all the #define and don't see a problem OR'ing constants as long as the OR'd variables are int64_t instead of the enum type.

For me it is more easily recognizable, what flags are grouped together, but I approved previous version, as it was looking nice too. Frankly I would leave the enum conversion to separate commit, if not PR, to not mix it with real fixes that are being made in this changes.

as the OR'd variables are int64_t instead of the enum type.

ok but that sounds easy to get wrong, no?

It's not like it doesn't work if the variable is of the enum type, it just makes more sense to use int if the value is not one of the enum constants. Also even this example in Microsoft's docs does it and even assigns the OR'd constants to Days variables: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/enum#enumeration-types-as-bit-flags

I wouldn't take MS documentation as the benchmark of correctness. There are many code examples from them that don't even work.

In fact, C++ enum classes are strongly typed and won't allow such usage, just like enum in most non-C programming languages.

If this is controversial we can leave it as defines, I don't mind either way, it's just a values.

kasper93 · 2024-12-28T13:34:21Z

Needs rebase.

kasper93 · 2024-12-31T10:23:13Z

options/m_option.h

+    UPDATE_CLIPBOARD       = (1 << 17), // reinit the clipboard
+    UPDATE_OPT_LAST        = (1 << 17),
+
+    M_OPT_NOCFG     = (1 << 30), // The option is forbidden in config files.


Now that the type has been changed to 64 bits, those should be moved up.

kasper93 · 2025-01-05T00:56:57Z

I think we can wait with this PR until next time we add new flag.

Dudemanguy · 2025-01-24T21:59:31Z

#15456 adds a new flag so I think this is probably relevant again?

guidocella · 2025-01-24T22:06:53Z

That was the motivation of this PR, but 2 more flags can be added after UPDATE_DEMUXER before having to convert flags to 64 bit.

guidocella · 2025-01-28T16:05:48Z

As the 2 remaining flags just got added tihs is now necessary to add more.

kasper93 · 2025-01-28T21:06:40Z

options/m_option.h

+enum option_flags {
+    // The following are also part of the M_OPT_* flags, and are used to update
+    // certain groups of options.
+    UPDATE_TERM            = (UINT64_C(1) << 0),  // terminal options


parentheses are not needed if we use enum

kasper93 · 2025-01-28T21:07:17Z

options/m_option.h

+    UPDATE_OPT_LAST        = (UINT64_C(1) << 20),
+
+    // The option is forbidden in config files.
+    M_OPT_NOCFG     = (UINT64_C(1) << 61),


Since we suppose to use uint64_t, top value can be << 63

kasper93 · 2025-01-28T21:08:37Z

options/m_option.h

-#define UPDATE_OPT_LAST         (1 << 26)
-
-// All bits between _FIRST and _LAST (inclusive)
+enum option_flags {


If this is controversial we can leave it as defines, I don't mind either way, it's just a values.

kasper93 · 2025-01-28T23:01:23Z

It still fails on win32 build.

EDIT: enum won't work on Windows, by default size deduction is disabled and enums are always int. See for more info https://learn.microsoft.com/en-us/cpp/build/reference/zc-enumtypes

kasper93 · 2025-01-31T05:15:08Z

This has to be updated too:

mpv/options/m_config_core.c

Line 499 in 86383ae

assert(!(subopts->change_flags & ~(unsigned)UPDATE_OPTS_MASK));

sfan5

lgtm

options/m_config_core.c

So that more UPDATE flags can be added. change_flags in m_config_core.h was already uint64_t. Co-authored-by: Kacper Michajłow <[email protected]>

sfan5 reviewed Dec 8, 2024

View reviewed changes

options/m_option.h Outdated Show resolved Hide resolved

options/m_option.h Outdated Show resolved Hide resolved

guidocella force-pushed the option-constants branch from 632096c to 5744771 Compare December 8, 2024 12:31