[Windows] Use portable version of strerror

[gkisalapl]

This PR is part of porting nntrainer to windows.
This PR replace using GNU specific function strerror_r with portable version std::strerror

Replace this:
https://linux.die.net/man/3/strerror_r
With:
https://en.cppreference.com/w/cpp/string/byte/strerror

Self-evaluation:

Build test: [X]Passed [ ]Failed [ ]Skipped
Run test: [X]Passed [ ]Failed [ ]Skipped

[EunjuYang]

LGTM. Please check the CI.

[skykongkong8]

You have to apply clang-format in order to pass the CI.
Please check the clang-format complaint, unittest_tflite_export.cpp

[gkisalapl]

You have to apply clang-format in order to pass the CI. Please check the clang-format complaint, unittest_tflite_export.cpp

I've run clang format, using following version:

$ clang-format --version
$ Ubuntu clang-format version 14.0.0-1ubuntu1.1

but it seems that on continues integration we're using some different version.
Do you know which exactly ?

[djeong20]

Hi @gkisalapl,

I wanted to let you know that I applied your work to my local setup and confirmed that my results match yours in unittest_tflite_export.cpp. I’m currently using clang-format version 10 on Ubuntu 20.04. Our CI environment operates on Ubuntu 24.04, which seems to be using a newer version of clang-format, likely version 16 or 18. For now, I think we can disregard this issue.

[baek2sm]

The strerror_r() function is similar to strerror(), but strerror_r() is thread safe function.
In Windows, a thread-safe function named strerror_s() is provided separately.
Nevertheless, will there be no issue when this modification is applied?

[gkisalapl]

The strerror_r() function is similar to strerror(), but strerror_r() is thread safe function. In Windows, a thread-safe function named strerror_s() is provided separately. Nevertheless, will there be no issue when this modification is applied?

Good point, thank you for this finding. In order to be 100% sure that we keep current functionality we should do:

#ifdef _WIN32
strerror_s(...)
#else
stderror_r(...)
#endif

but If we stick with portable non thread safe version stderror() the only drawback is that subsequent calls to strerror() may overwrite the buffer addressed by the returned pointer and print incorrect error message in result.
In order to make it happen we would need to report error by strerror() in 2 threads in similar time which is very unique situation I think. My recommendation is to go with portable version instead of making os specific calls.

[djeong20]

LGTM! please rebase to pass the CI 💯