strerror is now thread safe

[andrew-aitchison]

Before glibc 2.32, strerror() is not MT-Safe.
(from man strerror on Ubuntu 26.04).

glibc 2.32 was released on 2020-08-05 and glibc 2.43 on 2026-01-24
(from https://sourceware.org/glibc/wiki/Glibc%20Timeline)

This patch stops the threadsafety.py addon from warning about strerror().

strerror was used in test/cli/other_test.py to test threadsafety.py so we also patch that to use a different thread-unsafe function.

[andrew-aitchison]

I don't think the failing check reached my code. Can I run it again ?

[danmar]

This page:
https://en.cppreference.com/c/string/byte/strerror

Says:
"strerror is not required to be thread-safe"

[andrew-aitchison]

Hmm.
That is a change of spec since:
https://sourceforge.net/p/cppcheck/discussion/general/thread/209919289c/#2bf5

Spontanously I am skeptic about this warning. This warning will not age well if we keep it. In couple of years no recent distro will be unsafe.

How hard do we wish to work to avoid false-positives ?

I don't know whether other platforms have similar man-pages that could be used to generate a list for each platform. That might allow us to ship multiple lists and let the user select which ones they wish to be warned about ?

On the other hand; are how important is it to find POSIX issues as well C/C++ problems in user's code ?

[danmar]

Because it's a "warning" it's a false positive for those that uses glibc and that is not nice.

We could change the severity to "portability" for functions where the standard does not clearly say if it's thread safe or not. It is not a false positive to say that it's a portability issue.

if we add "strerror" as a symbolname to the error message then users will be able to suppress such portability warnings for this function.

[andrew-aitchison]

We could change the severity to "portability" for functions where the standard does not clearly say if it's thread safe or not.

The current list is machine generated from Linux man pages, but they don't indicate whether the standard is or is not thread safe in the same manner. I can look at the standard and see how easy it would be to extract that information, but that might require a more intelligent reading of the standard - the current method relies on how the man pages are structured.

In the short term would it make sense to always mark these as "portability" ?

Do you have a pointer to "the standard" ?

[danmar]

In the short term would it make sense to always mark these as "portability" ?

I am not totally against that.. but I don't have the bigger picture. Is the bigger picture that we need an exception just for strerror or that there are several functions that are thread safe in posix but according to the C standard they are not required to be thread safe..

Do you have a pointer to "the standard" ?

I typically just google "C11 pdf" or "C23 pdf" or something like that:
C11 : https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
C23 : https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3088.pdf

both those standards say that "strerror is not required to avoid data races".

[danmar]

if you somehow hardcode that strerror should generate a portability warning instead I would be happy. I feel that the text in the C standards motivate this.

[andrew-aitchison]

I feel that the text in the C standards motivate this.

I don't disagree.

I don't have the bigger picture. Is the bigger picture that we need an exception just for strerror or that there are several functions that are thread safe in posix but according to the C standard they are not required to be thread safe..

Good question. I don't know the answer.
I only discovered the change in strerror when I upgraded and noticed that the rebuilt list of unsafe functions had changed (I have a cron job to check for me).

I'm also not sure that POSIX says that strerror is thread safe, or just that it is safe in sufficiently new GNU C libraries.
I note that C23 adds a function strerror_s which is thread safe, ... but not part of libc6 as of v2.43.

Perhaps the answer is to leave strerror marked as unsafe, since strerror_s suggests that strerror never will be guaranteed safe.

My concern is that the whole of the output that I added of the addon is based on a (non AI) machine reading of the linux man pages on the build machine. We cannot really assume that will avoid false positives.
I could split this off from the original thread-safety addon, making it into a new addon of its own, which we could document as at risk of false positives.

My original idea was to have different function lists for different platforms and users could decide which if any to use, but I don't have access to other platforms (unless I can get github to do something ... ).

[danmar]

Perhaps the answer is to leave strerror marked as unsafe, since strerror_s suggests that strerror never will be guaranteed safe.

yes sure.

My concern is that the whole of the output that I added of the addon is based on a (non AI) machine reading of the linux man pages on the build machine.

Non AI approach means it's deterministic and doesn't get bored. Are you concerned that functions were wrongly identified as dangerous, and that it leads to false positives?

I could split this off from the original thread-safety addon, making it into a new addon of its own, which we could document as at risk of false positives.

I feel we should try to mitigate the risk for false positives. Some double checking that added functions are in deed dangerous.

[danmar]

My original idea was to have different function lists for different platforms and users could decide which if any to use, but I don't have access to other platforms (unless I can get github to do something ... ).

It sounds more precise.

But spontanously it also sounds pretty hard to maintain for us and configure for users. So I am skeptic. But it's possible to convince me..

If direct access to the platform is needed to generate the output then it might be better that the user runs the script that generates the output?

[andrew-aitchison]

If direct access to the platform is needed to generate the output then it might be better that the user runs the script that generates the output?

Tempting, but then users would not have the data from other platforms needed to generate some portability warnings. Though at present we only have data from GNU libc ...

Are you concerned that functions were wrongly identified as dangerous, and that it leads to false positives?

I'm comfortable that we wont get false positives (since we only mark functions described as Unsafe) in GNU libc.
(strerror is of course an example of a false negative).

Perhaps the answer is to leave strerror marked as unsafe, since strerror_s suggests that strerror never will be guaranteed safe.

yes sure.

I'm coming around to the idea that strerror is a genuine exception. I'll see whether I can mark it as a portability issue.