Hello Johannes,
Johannes Brunen wrote:
> "Carsten Neumann" <carsten_neum...@gmx.net> schrieb im
> Newsbeitrag news:4c4dbd03.5060...@gmx.net...
>>> I could verify that everything is fine to the point of the return call.
>>> However, variable v is not correctly intialized afterwards.
>> oh, my favourite C++ programming rules, aliasing ;) My hope in writing
>> the above had been that due to the special casing of 'char' in the
>> aliasing rules the conversion would be safe :-/
>>
> No, I do not think that it is an aliasing problem. After applying your patch
> the behavior did not change. I have minutely debugged and see the same bit
> switch on assigment to variable v in function
hm, thanks for the detailed analysis and sorry the patch did not work, I
had not expected that something would mess with the swapped Real32 value
(even if the bit pattern indicates a NaN after the swap).
> ExceptionBinaryDataHandler::putValue(const Real32& value)
>
>
> For example: In function
>
> template<> inline
> OSG::Real32 osgSwapBytes<Real32>(OSG::Real src)
> {
> union
> {
> OSG::Real32 floatVal;
> OSG::UInt32 intVal;
> } unionVal;
>
> unionVal.floatVal = src;
> unionVal.intVal = osgSwapBytes(unionVal.intVal);
>
> return unionVal.floatVal;
> }
>
> I got at the address of unionVal the following: 43 ea 91 ff
>
> After assignment to variable v I got at the address of v: 43 ea d1 ff
>
> I take my suspicion that the problem is related to the numerics. I do not
> believe that it is reasonable to expect the runtime to copy/assign real
> numbers only with respect to their bit representation uniformely on all
> platforms. The math coprocessor is typically involved on x86.
hm, on Linux we use compiler options to use SSE instead of the FPU,
which I would expect reduces the risk of float getting garbled (AFAIU
the SSE registers are 64 bit not 80 bit like the FPU).
Anyway, out of curiosity, do you use different compiler switches from
OpenSG's defaults?
> Maybe someone with knowledge in this matter does listen and can give a
> statement?
indeed, that would be great :)
I have one other idea how to work around this [1], but have to admit
that I'm at the point where I don't really understand these things well
enough to have much confidence even if the proposed patch should happen
to work.
Cheers,
Carsten
[1] basically it removed the regular osgSwapBytes() overloads for
Real32/Real64 and added two parameter versions:
void osgSwapBytes(Real32 src, UInt32 &dest);
void osgSwapBytes(UInt32 src, Real32 &dest);
// similar for Real64
so that the swapped representation of a Real32 would only be passed
around as UInt32 and not as a Real32 any more. Unfortunately this
requires a bunch of changes throughout OpenSG and I have not finished
the patch yet.
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
