Avoid MT-Unsafe functions

[franzhollerer]

Please avoid the use of functions which are known to be not Thread-safe (POSIX: MT-Unsafe).

Related: #412

Rational: I understand that the libmodbus library is not thread safe by its own. I can deal with that by ensuring that the library is used in a single dedicated thread, or by serialization.

Unfortunately, the library itself uses MT-Unsafe functions, e.g the modbus_strerror() calls strerror().

I cannot protect from competing calls to strerror() whithout modifying the libmodbus code and call serialization of the MT-Unsafe function. Being said, it is not sufficient to serialize access to the library in order to use it in a multithreaded environment, if the library itself calls MT-Unsafe functions.

[franzhollerer]

The static code analysis tool CodeSonar reports the following use of MT-Unsafe functions:

• modbus-rtu.c, function _modbus_rtu_connect(): use of MT-Unsafe function strerror()
• modbus-tcp.c, function modbus_tcp_listen(): use of MT-Unsafe function perror() (several times)
• modbus.c, function modbus_strerror() use of MT-Unsafe function strerror()

[franzhollerer]

According to the Linux man page the function perror() is "MT-safe race:sterror". To my understanding the output my intermix if perror() is called concurrently from different threads

Looking at the POSIX standard , perror() is not listed among the functions which need not be thread-safe. See: https://pubs.opengroup.org/onlinepubs/7908799/xsh/threads.html

Intermixing the output might be unpleasant but does not cause any harm. Therefore, I think we can consider perror() as thread-safe.

What remains is strerror() which should be addressed.