Hi Erik, On 2018-12-12 at 15:41 +0300, Boris Ulasevich wrote: > Hi Jakub, > > I do not understand why you use memcpy in softfloat_arm.cpp. > If type cast is the only reason why don't you use reinterpret_cast? > > regards, > Boris
I'm using memcpy there because float32_t is a struct containing a single uint32_t member. I think that the proper way of doing a byte- level conversion between different types (type punning) is via memcpy. If I used a casted pointer, this would violate the rule that I can access a memory location through a pointer of only one type. Using union for this seems to be also undefined in C++, as then I would access the value through a non-active member. Thanks, Jakub > > On 10.12.2018 23:23, Jakub Vaněk wrote: > > Hi Erik, > > > > On 2018-12-10 at 09:39 -0800, Erik Joelsson wrote: > > > The build changes look ok to me. > > > > > > I do think --enable-softfloat is redundant as using any of the > > > other > > > parameters would imply it to be set, but it's ok to have it > > > there. > > > > Thanks for the review. The motivation for this was that I was > > closely > > following how libffi is handled. The enable option was a workaround > > for > > the detection of softfloat in system paths. I don't think this is > > how > > the library is going to be used, so I removed this option. > > > > New patch can be found here: > > https://github.com/ev3dev-lang-java/openjdk-ev3/blob/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > > > Regards, > > > > Jakub > > > > > > > > /Erik > > > > < raw patch at > > https://raw.githubusercontent.com/ev3dev-lang-java/openjdk-ev3/78a9d35986ed51273d9a3bb9878cbfcbe2488bfb/upstream/softfloat.patch > > > > >
