Work around unexpected data_value constructor

If someone tried to naively use utf8_type->decompose("18wX"), this would
mysteriously fail, returning an empty key.

decompose takes a data_value, so the compiler looked for an implict
conversion from the string constant (const char*) to data_value. We did
not have such a conversion, only conversion from sstring. But the compiler
chose (backed by the C++ standard, no doubt) to implicitly convert the
const char* to a bool (!), and then use data_value(bool). It did not
convert the const char* to an sstring, nor did it warn about the possible
ambiguity.

So this patch adds a data_value(const char*) constructor, so people will
not fall into the same trap that I fell into...

Signed-off-by: Nadav Har'El <nyh@scylladb.com>
Message-Id: <1467643462-6349-1-git-send-email-nyh@scylladb.com>

types.cc

@@ -2885,6 +2885,9 @@ data_value::data_value(bytes v) : data_value(make_new(bytes_type, v)) {
 data_value::data_value(sstring v) : data_value(make_new(utf8_type, v)) {
 }
 
+data_value::data_value(const char* v) : data_value(make_new(utf8_type, sstring(v))) {
+}
+
 data_value::data_value(bool v) : data_value(make_new(boolean_type, v)) {
 }
 

types.hh

@@ -308,6 +308,7 @@ public:
     // note: somewhat dangerous, consider a factory function instead
     explicit data_value(bytes);
     data_value(sstring);
+    data_value(const char*);
     data_value(bool);
     data_value(int32_t);
     data_value(int64_t);