Change line endings from \r\n to \n only

[andresag01]

This makes the new line printing consistent across all the sample applications. This change is a superset of #123.

[JanneKiiskila]

Looks good!

[RonEld]

There are platforms, that if you don't put \r, then the cursor will not move to beginning of the line, and doing \n the print will just start from next line, but same row. I think it's better to keep r\n , and perhaps consider doing it across all of our prints

[JanneKiiskila]

@RonEld - what do you mean with OTHER platforms? This repository is for mbed-os, right? Isn't Mbed OS then the only platform we need to consider with regards to this repository?

• all known boards I've tried so far do work with the \n once the mbed_app.json is set up correctly.
• platforms that do not adhere to a normal \n could be stated to violate the C-standards.

[RonEld]

@JanneKiiskila I meant platforms, as in boards, not OS. I tried on NRF52840 , and I didn't get the newline at the beginning of the line. However, perhaps it is because of missing "platform.stdio-convert-newlines": true in the mbed_app.json . I'll check

[RonEld]

I checked, and after modifying mbed_app.json, it works

[k-stachowiak]

Looks Good To Me

[JanneKiiskila]

Merge it in!

[andresag01]

@sbutcher-arm, @Patater: What are the plans for this patch? Please note that it is very out of date. Should I rebase/rework it?

[simonbutcher]

@andresag01 - Yes, please rebase it. @k-stachowiak and @AndrzejKurek should then review again afterwards.

Thanks.

[andresag01]

I have rebased the changes but the CI needs to be re-run to ensure that the expected regex patterns still match.

[k-stachowiak]

I looked at the test failure logs. I found two failures, one known - memory allocation issue, and one new - apparently a stack overflow. This may be a CI stability issue, or, as a memory issue, related to the known one.

[andresag01]

@k-stachowiak: I think these issues are not directly related to this change. The benchmark application is clearly having trouble to stay within the allocated stack. If I had to guess, I would say the other targets tested are also having overflow problems, but it is probably not detected.

At first glance, it seems that the new test_crypt and test_rng functions in the benchmark application have a relatively high stack of over 772 bytes and 624 bytes respectively. Given that this is only the 3 or so function in the call stack its not surprising that at some point there is an overflow if the overall stack size is about 3-4KB

[k-stachowiak]

@andresag01 Thanks for the clarification. I too don't see a connection between the CI errors and the PR changes. Additionally, since my approval was not cancelled by the updates, I'll just confirm commenting, that I approve the rebased chages.

[simonbutcher]

CI failures are due to heap and stack depletion - known issues. Therefore - labelling as 'ready for merge'.