from ctypes import *
import struct

i = int('7f94e57c', 16)
cp = pointer(c_int(i))
fp = cast(cp, POINTER(c_float))
print(fp.contents.value) # nan
print(struct.pack(">f", fp.contents.value).hex()) # 7fd4e57c

# value changed: 7f94e57c -> 7fd4e57c

It's reproducible only if the float is nan, with prefix 7f or ff.
Seems the value is OR operated by 0x00400000.

Also reproducible by:

from ctypes import *
 
i = int('7f94e57c', 16)
cp = pointer(c_int(i))
fp = cast(cp, POINTER(c_float))
print(fp.contents.value) # nan
p = pointer(c_float(fp.contents.value))
ip = cast(p, POINTER(c_int))
print(hex(ip.contents.value)) #'0x7fd4e57c'

I believe that this may be the same issue as this thread

https://mail.python.org/archives/list/python-dev@python.org/thread/35NECLGFIVAHWTIPAYDBJOJJX3FSY233/

in particular this comment:

https://mail.python.org/archives/list/python-dev@python.org/message/QIC4DLFYEI3IVGUFK5KRTIELTKFI76B6/

There's an implicit float-to-double conversion here (`fp.contents.value` is represented as a Python float, which is backed by a C double). What you're seeing is that converting the single-precision signaling NaN to double precision loses the signaling bit, producing a quiet double-precision NaN with the same sign and payload (modulo the signaling bit). That's what I'd expect under IEEE 754 semantics. (IEEE 754-2008 says, in section 6.2, "Under default exception handling, any operation signaling an invalid operation exception and for which a floating-point result is to be delivered shall deliver a quiet NaN.".)

I don't think there's anything we can or should do about this at Python level. ctypes is correctly reflecting the existing C-level behaviour. In other words, this is expected behaviour, not a bug.

OK. Seems it's the default behavior of CPU instruction. And CPU follows the IEEE standard of float. 

Is there any workaround?

> Is there any workaround?

Sorry, I can't answer that without knowing what it is you're trying to do - that is, I don't know which part of the behaviour you want a workaround for. But that's getting off topic for this tracker, which is for bug reporting; I'd suggest taking the discussion to one of the mailing lists, Stack Overflow, or some other resource.