Issue 71762 - warning: operation on 'pPtr' may be undefined
Summary: warning: operation on 'pPtr' may be undefined
Status: CLOSED FIXED
Alias: None
Product: porting
Classification: Code
Component: code (show other issues)
Version: 680m193
Hardware: Sun Linux, all
: P3 Trivial (vote)
Target Milestone: OOo 2.2
Assignee: Stephan Bergmann
QA Contact: issues@porting
URL:
Keywords:
Depends on:
Blocks: 67001
  Show dependency tree
 
Reported: 2006-11-20 08:53 UTC by sparcmoz
Modified: 2006-12-05 10:50 UTC (History)
2 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
remove pointer decrements (742 bytes, patch)
2006-11-20 21:22 UTC, sparcmoz 		no flags Details | Diff
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description sparcmoz 2006-11-20 08:53:21 UTC 
Building with warnings are errors on GNU/Linux SPARC and gcc4.1.2:
 -o ../../../unxlngs.pro/slo/enhwmf.o /home/jim/vanilla/svtools/source/filter.vcl/wmf/enhwmf.cxx 
cc1plus: warnings being treated as errors
/home/jim/vanilla/svtools/source/filter.vcl/wmf/enhwmf.cxx: In function 'float GetSwapFloat
(SvStream&)':
/home/jim/vanilla/svtools/source/filter.vcl/wmf/enhwmf.cxx:180: warning: operation on 'pPtr' may be 
undefined
dmake:  Error code 1, while making '../../../unxlngs.pro/slo/enhwmf.obj'
'---* tg_merge.mk *---

The relevant code with added **comment**:

#ifdef OSL_BIGENDIAN
// currently unused
static float GetSwapFloat( SvStream& rSt )
{
        float   fTmp;
        sal_Int8* pPtr = (sal_Int8*)&fTmp + 3;
        rSt >> *pPtr-- >> *pPtr-- >> *pPtr-- >> *pPtr;  // Little Endian <->  **line 180**
        return fTmp;
}
#endif
Comment 1 sparcmoz 2006-11-20 09:07:46 UTC 
@sb: any comment would be appreciated. The #ifdef OSL_BIGENDIAN was introduced in rev1.30 to remove 
errors for Linux so I guess there is not a simple fix.
Comment 2 sparcmoz 2006-11-20 10:47:55 UTC 
The following patch builds without warnings, but I have no idea what is the real right sequence of 
operations here, it just looks better logically to do the >> operation before decrementing (assuming left 
to right):
-       rSt >> *pPtr-- >> *pPtr-- >> *pPtr-- >> *pPtr;  // Little Endian <-> Big Endian switch
+       rSt >> *pPtr >> --*pPtr >> --*pPtr >> --*pPtr;  // Little Endian <-> Big Endian switch
Comment 3 Stephan Bergmann 2006-11-20 12:55:19 UTC 
Completely remove the multiple side-effects of decrementing pPtr:

sal_Int8* pPtr = (sal_Int8*)&fTmp;
rSt >> pPtr[3] >> pPtr[2] >> pPtr[1] >> pPtr[0];
Comment 4 sparcmoz 2006-11-20 21:22:45 UTC 
Created attachment 40778 [details]
remove pointer decrements
Comment 5 sparcmoz 2006-11-20 21:24:10 UTC 
reassign and start
Comment 6 sparcmoz 2006-11-20 21:25:00 UTC 
.
Comment 7 sparcmoz 2006-11-20 21:50:53 UTC 
started
Comment 8 sparcmoz 2006-11-21 08:04:35 UTC 
committed in cws_src680_jw3
Comment 9 sparcmoz 2006-11-21 09:24:07 UTC 
reassign for qa
Comment 10 Stephan Bergmann 2006-11-22 13:12:27 UTC 
According to sj there is no easy way to test this code.  Thus verified by code
review.
Comment 11 sparcmoz 2006-12-05 10:50:10 UTC 
Integrated in m196