tests: net: lib: lwm2m: fix the missing float support

[SgrrZhf]

The tests content_json and content_plain_test depend on the float support of libc. After PR##57340, Picolibc would be selected in these two tests and the PICOLIBC_IO_FLOAT won't be selected if the platform doesn't select FPU.

This commit select CONFIG_PICOLIBC and CONFIG_PICOLIBC_IO_FLOAT for these two tests.

[jukkar]

Hmm, if picolib would be used by default, then we should not need the CONFIG_PICOLIBC=y or did I misunderstood something?
I am not convinced that we should select config options like this, what if user running the test does not want to use picolib.

[SgrrZhf]

if picolib would be used by default, then we should not need the CONFIG_PICOLIBC=y

Sure, I'll delete it.

[SeppoTakalo]

Well, if tests are broken because of default configs, should we fix the default config instead of modifying the test configuration?

I noticed also another problem with Picolib #62444
So I think we need to consider whether LwM2M should require Newlib, or some other C library. Or should we just ignore some of the text-formatting issues?
After all, I don't think any realistic use case would use clear text, or JSON, based formats in product. It is just for development and debugging phase.

[jukkar]

So I think we need to consider whether LwM2M should require Newlib, or some other C library. Or should we just ignore some of the text-formatting issues?

IMHO, for tests the most important thing is that it (the test) verifies that some functionality works ok. So with this in mind, the textual output of the test might not matter that much. Unless we should be verifying that the output of some print is correct, but I think that is not the case here.

For some other components than tests, I think it depends how important is it that the output is valid. I have encountered this few years go with gPTP and the net-shell where some 64-bit values were not printed correctly with minimal libc. I decided to ignore the issue as the printing was fixed eventually and the output was not that important for the user.

[SeppoTakalo]

So with this in mind, the textual output of the test might not matter that much. Unless we should be verifying that the output of some print is correct, but I think that is not the case here.

In these tests, we are in fact verifying the output of string formatting functions:

zephyr/tests/net/lib/lwm2m/content_plain_text/src/main.c

Lines 224 to 227 in efeb2d1

	double value[] = { 0., 0.123, -0.987, 3., -10., 2.333, -123.125 };
	char * const expected_payload[] = {
	"0.0", "0.123", "-0.987", "3.0", "-10.0", "2.333", "-123.125"
	};

So there is a known floating point value, and known text output that it should produce.
Without the config, the textual content format are completely unable to produce floating point values and integers bigger than 32 bit.
Whether this is a problem or not, is up to discussion. I'm starting to lean towards ignoring this issue as long as it is documented. I would leave it up to developer to choose if they need clear text formats, or should they use binary ones.