json::from_cbor does not respect allow_exceptions = false when input is string literal

[misos1]

• What is the issue you have?

Function json::from_cbor throws exception even with allow_exceptions = false when input is string literal.

• Please describe the steps to reproduce the issue. Can you provide a small but working code example?

#include <stdio.h>
#include "json.hpp"

using namespace nlohmann;

int main()
{
	json cbor = json::from_cbor("A", true, false);
	printf("is_discarded: %i\n", cbor.is_discarded());
	return 0;
}

Note json::from_cbor:

    static basic_json from_cbor(detail::input_adapter&& i,
                                const bool strict = true,
                                const bool allow_exceptions = true)

• What is the expected behavior?

It should print is_discarded: 1.

• And what is the actual behavior instead?

Throws exception:

terminate called after throwing an instance of 'nlohmann::detail::parse_error'
  what():  [json.exception.parse_error.112] parse error at byte 1: syntax error
while parsing CBOR value: invalid byte: 0x41
exited, aborted

• Which compiler and operating system are you using? Is it a supported compiler?

Clang 7.

[nlohmann]

This is strange:

First off, changing the literal to a std::string does the job:

    json cbor = json::from_cbor(std::string("A"), true, false);
    printf("is_discarded: %i\n", cbor.is_discarded());

output:

is_discarded: 1

This code correctly selects this function:

static basic_json from_cbor(detail::input_adapter&& i,
                            const bool strict = true,
                            const bool allow_exceptions = true)

The original code, however, uses this function:

template<typename A1, typename A2,
         detail::enable_if_t<std::is_constructible<detail::input_adapter, A1, A2>::value, int> = 0>
static basic_json from_cbor(A1 && a1, A2 && a2,
                            const bool strict = true,
                            const bool allow_exceptions = true)

Binding a1 to char const (&)[2] and a2 to true and strict to false. As no fourth parameter is given, allow_exceptions is true. Hence the exception.

That version of from_cbor is chosen, because we can construct an input_adapter with a char pointer and std::size_t using this constructor:

template<typename CharT,
         typename std::enable_if<
             std::is_pointer<CharT>::value and
             std::is_integral<typename std::remove_pointer<CharT>::type>::value and
             sizeof(typename std::remove_pointer<CharT>::type) == 1,
             int>::type = 0>
input_adapter(CharT b, std::size_t l)
    : ia(std::make_shared<input_buffer_adapter>(reinterpret_cast<const char*>(b), l)) {}

Unfortunately, I do not know how to avoid the conversion from bool to std::size_t in this setting.

[t-b]

@nlohmann

At least the example here works with just

$git diff .
diff --git a/single_include/nlohmann/json.hpp b/single_include/nlohmann/json.hpp
index 2a32a829..d2d3ccf3 100644
--- a/single_include/nlohmann/json.hpp
+++ b/single_include/nlohmann/json.hpp
@@ -4107,13 +4107,14 @@ class input_adapter
         : ia(std::make_shared<wide_string_input_adapter<std::u32string>>(ws)) {}
 
     /// input adapter for buffer
-    template<typename CharT,
+    template<typename CharT, typename SizeT,
              typename std::enable_if<
                  std::is_pointer<CharT>::value and
                  std::is_integral<typename std::remove_pointer<CharT>::type>::value and
+                 not std::is_same<SizeT, bool>::value and
                  sizeof(typename std::remove_pointer<CharT>::type) == 1,
                  int>::type = 0>
-    input_adapter(CharT b, std::size_t l)
+    input_adapter(CharT b, SizeT l)
         : ia(std::make_shared<input_buffer_adapter>(reinterpret_cast<const char*>(b), l)) {}
 
     // derived support

but I'm probably missing a billion things.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.