unexpected leading zero in configuration values

[rkaminsk]

When printing the values of top level configuration entries, the meta value configuration is prefixed with a zero. Is this intended?

Tested on the dev-20 branch:

configuration: "0auto"
share: "auto"
learn_explicit: "0"
short_simp_mode: "no"
sat_prepro: "no"
stats: "no,0"
parse_ext: "false"
parse_maxsat: "false"

[BenKaufmann]

@rkaminsk Do you have any steps to reproduce for this?
There are a couple of unit tests checking the value of the configuration option and all of them pass on the branch.

Furthermore, for me the following two assertions added to parsertest/lib/c-api/src/main.cc also pass:

auto p = claspConfig_.getValue("configuration");
assert(p == "auto");

and

auto k = claspConfig_.getKey(Clasp::Cli::ClaspCliConfig::key_root, "configuration");
char buffer[64];
auto x = claspConfig_.getValue(k, buffer, sizeof(buffer));
assert(x == 4 and std::strcmp(buffer, "auto") == 0);

[rkaminsk]

Sorry, my bad. It seems like

int ClaspCliConfig::getValue(KeyType key, std::string& out) const

sometimes clears the string it receives and sometimes it appends to it. I should simply clear the (reusable) string I am passing. (See lib/c-api/src/config.cc:179.)

[BenKaufmann]

You are right. The current behavior of getValue is indeed inconsistent (and undocumented). I'll put it on my todo list.
In any case, clearing the string you are passing seems to be a good/robust idea.

[rkaminsk]

Passing an empty string was what I intended anyway. I just forget to actually do it.

Looking at the interface from a practical point of view, I don't think that appending to a string is a very common use case. It would however be the more flexible variant. The use case in clingo, which is probably the only one we have, requires setting the string to the value - there is no need to append.