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.