This fixes a build error regression on mingw64 introduced by me in
16beec98d26644b96d57bd8da477166d0bc7d05c
In get_hold_current_qp, uint32_t variables were improperly
used to hold the value of reader_idx, which is defined as long int.
So I used CRYPTO_atomic_load_int, where a comment states
On Windows, LONG is always the same size as int
There is a size confusion, because
Win32 VC x86/x64: LONG, long, long int are 32 bit
MingW-W64: LONG, long, long int are 32 bit
cygwin64: LONG is 32 bit, long, long int are 64 bit
Fix:
- define reader_idx as uint32_t
- edit misleading comment, to clarify:
On Windows, LONG (but not long) is always the same size as int.
Fixes the following build error, reported in [1].
crypto/threads_win.c: In function 'get_hold_current_qp':
crypto/threads_win.c:184:32: error: passing argument 1 of 'CRYPTO_atomic_load_int' from incompatible pointer type [-Wincompatible-pointer-types]
184 | CRYPTO_atomic_load_int(&lock->reader_idx, (int *)&qp_idx,
| ^~~~~~~~~~~~~~~~~
| |
| volatile long int *
[1] https://github.com/openssl/openssl/pull/24405#issuecomment-
2211602282
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/24803)
struct rcu_qp *qp_group;
size_t group_count;
uint32_t next_to_retire;
- volatile long int reader_idx;
+ uint32_t reader_idx;
uint32_t current_alloc_idx;
uint32_t writers_alloced;
CRYPTO_MUTEX *write_lock;
return 1;
#else
- /* On Windows, LONG is always the same size as int. */
+ /* On Windows, LONG (but not long) is always the same size as int. */
*ret = (int)InterlockedOr((LONG volatile *)val, 0);
return 1;
#endif