Metatable::is_property_key seems flawed

[iar74]

in metatable.cpp, l. 84ff:

inline bool is_property_key(const char *keyname) {
return keyname &&
strncmp(keyname, KAGUYA_PROPERTY_PREFIX,
sizeof(KAGUYA_PROPERTY_PREFIX) - 1) != 0;
}

returns true for any keyname that does NOT start with KAGUYA_PROPERTY_PREFIX. (strncmp returns 0 if the prefix matches).

Not sure this is intended.

However, if it is changed to:

inline bool is_property_key(const char *keyname) {
return keyname &&
(strncmp(keyname, KAGUYA_PROPERTY_PREFIX,
sizeof(KAGUYA_PROPERTY_PREFIX) - 1) == 0);
}

nothing works anymore (I am exaggerating, but even though not all, it feels like all).

I am trying to isolate the problem, but maybe you have some thoughts to share on what is actually intended here?

What is the reason for using the KAGUYA_PROPERTY_PREFIX at all?

[iar74]

I have dug a little deeper. Please review my attempt to fix the issue with d5f1e3b.
This fixes c-sided access to static fields, as those were matched against a prefixed _prop_ variable name.
The old implementation (and my suggestion) both suffer from the problem, that properties may not be added using .addProperty("_prop_<whatever>", &foo::whatever), as the adding of the "_prop_" prefix for properties creates a property named "_prop__prop_<whatever>", which is then searched as "_prop_<whatever>" in the metatable due to the match in the pre-fix. Given your current design, this is a documentation issue IMO, i.e., never prefix your properties "_prop_" in c-code.
Please let me know your thoughts, maybe I did not get your intentions right here.