Allow Zephyr build w/o having posix api enabled

[mstaz]

Description

At the moment the Zephyr integration requires POSIX API (CONFIG_POSIX_API) to be enabled. However this causes build issues when picolib instead of newlib is enabled (at least for Zephyr 4.3). Luckily the POSIX API isn't really necessary anymore as nearly everything is updated to Zephyr core API already.
So the checks can be updated. One place where the POSIX API was still left was memory tracking (WOLFSSL_TRACK_MEMORY) which was easy to update to wolfSSL's own abstraction layer.

Testing

Building a modified version of the tls_sock example and ran it directly on the target.

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[wolfSSL-Bot]

Can one of the admins verify this patch?

[Copilot]

Pull request overview

Updates wolfSSL’s Zephyr integration to remove the hard dependency on Zephyr’s POSIX API, improving compatibility with libc configurations (e.g., picolibc) while keeping threading and time support working via Zephyr core APIs.

Changes:

• Relax Zephyr threading header/config requirements by avoiding POSIX pthread includes on newer Zephyr kernels.
• Adjust Zephyr time mappings to better support builds where POSIX clock APIs aren’t available.
• Switch memory tracking (WOLFSSL_TRACK_MEMORY) locking from pthread_mutex_* to wolfSSL’s mutex abstraction (wc_LockMutex / wc_UnLockMutex).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
wolfssl/wolfcrypt/wc_port.h	Removes reliance on Zephyr POSIX pthread headers for newer kernels; adjusts clock macro mappings for Zephyr.
wolfssl/wolfcrypt/mem_track.h	Replaces pthread mutex usage with wolfSSL mutex abstraction for memory tracking.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dgarske]

Okay to test. Contributor agreement on file.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #10325

No scan targets match the changed files in this PR. Review skipped.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Mapping clock_gettime/clock_settime unconditionally when SYS_CLOCK_REALTIME is defined can break builds when a libc already provides clock_gettime (e.g., macro/function redefinition or signature mismatch). Consider only defining these aliases when clock_gettime/clock_settime are not already provided (or when CLOCK_REALTIME is missing), mirroring the previous guard behavior.

Suggested change

	#endif
	#define clock_gettime sys_clock_gettime
	#define clock_settime sys_clock_settime
	#define clock_gettime sys_clock_gettime
	#define clock_settime sys_clock_settime
	#endif

[Copilot]

On platforms where WOLFSSL_MUTEX_INITIALIZER is not available, memLock is only initialized in InitMemoryTracker(), but TrackMalloc()/TrackFree()/ShowMemoryTracker() can attempt to lock it regardless. This is a regression versus the previous statically-initialized pthread_mutex_t and can lead to locking an uninitialized mutex. Fix by ensuring the mutex is initialized before any lock attempt (e.g., lazy one-time init in the locking path, or guaranteeing initialization before installing/using the tracking allocators).

[Copilot]

wc_InitMutex(&memLock) is called without checking its return value, and it may be called multiple times if InitMemoryTracker() can be invoked more than once (double-init / resource leak risk depending on the platform implementation). Consider guarding initialization with a static 'initialized' flag and handling wc_InitMutex failures (e.g., returning an error from InitMemoryTracker() when initialization fails).

[Copilot]

wc_FreeMutex(&memLock) is unconditional (when WOLFSSL_MUTEX_INITIALIZER is not defined) but there’s no guarantee the mutex was successfully initialized (or initialized at all, if cleanup can run without prior init). Consider freeing only when initialization succeeded (e.g., via an initialization flag set after a successful wc_InitMutex).

Suggested change

	wc_FreeMutex(&memLock);
	if (wc_MemStats_Ptr != NULL) {
	wc_FreeMutex(&memLock);
	}