Please don't remove the check for HAVE_ATOMIC as that is required for the feature to work in general and implies HAVE_STDATOMIC_H via autotools/CMake.

Does this fix a problem or why this change? As @mback2k says, I don't think the current approach is wrong.

If its the case that HAVE_ATOMIC means HAVE_STDATOMIC_H that's simply not true. On PlayStation 4 I'm getting HAVE_ATOMIC as true from the CMake build, but HAVE_STDATOMIC_H is false so easy_lock does not compile.

All the curl functions in easy_lock.h rely on atomic functions defined in stdatomic.h so HAVE_STDATOMIC_H looks to be the correct guard.

The only other case of HAVE_ATOMIC in the codebase is in CurlTests.c which guards HAVE_STDATOMIC_H.

If its the case that HAVE_ATOMIC means HAVE_STDATOMIC_H that's simply not true. On PlayStation 4 I'm getting HAVE_ATOMIC as true from the CMake build, but HAVE_STDATOMIC_H is false so easy_lock does not compile.

All the curl functions in easy_lock.h rely on atomic functions defined in stdatomic.h so HAVE_STDATOMIC_H looks to be the correct guard.

That is true and I guess the correct approach would be to check for both HAVE_ATOMIC and HAVE_STDATOMIC_H then as the test (see below) can also work without HAVE_STDATOMIC_H as you experienced.

The only other case of HAVE_ATOMIC in the codebase is in CurlTests.c which guards HAVE_STDATOMIC_H.

That is the place there the functional test for atomic support is done. HAVE_ATOMIC is defined during the test and if it compiles it will be defined for the curl build.

Updated to have both checks.

Thanks!