🚀 go-pugleaf

In article <BA54E438.7596%jbotwick@nc.rr.com>,
 Jason Botwick <jbotwick@nc.rr.com> wrote:

Hi,

In optimized code the actual code could be moved elsewehre or replaced 
so the value in the register does not reflect the variable when you 
think it should.

So I don't think this is a debugger bug.  However if you feel there is 
an optimization bug please submit this as a bug report to 
cw_bug@metrowerks.com  so we can look at it deeper.  Include a project 
that demonstrates the behavior.

Thanks, for the cooperation,

Ron
>
>void TBlockStreamDocument::ReserveDiskSpace(long long &requestedSpace)
>{
>    HParamBlockRec pb;
>    long long freeBytes;
>
>    BlockZero_AC(pb);
>
>    if (fDocStream->GetFile()->GetVolumeInfo(pb) == noErr)
>    {
>        // pb.*.* are both unsigned longs that return the amount
>        // of free disk blocks and the size of these blocks, respectively.
>
>        long long ioVFrBlk = pb.volumeParam.ioVFrBlk;
>        long long ioVAlBlkSiz = pb.volumeParam.ioVAlBlkSiz;
>        freeBytes = ioVFrBlk * ioVAlBlkSiz;
>    }
>    else
>        freeBytes = 0;
>    
>    if (freeBytes < requestedSpace)
>        requestedSpace = 0;
>}
>
>In my debug version of this app (optimization level 0), this works as
>expected. In my release version (optimization level 4), this function sets
>requestedSpace to 0 every time, because freeBytes always is set to 0. During
>debugging, I can see that the "if" block is always executed in both the
>release and debug versions. However, if I look at the variables window, in
>the debug version, I can see where freeBytes is set to the appropriate value
>in the debug version. But in the release version, the "value" of freeBytes
>according to the debugger is  "*Buffer for SetVariable must be exact size of
>variable*"
>
>WTF?
>
>No idea what that is supposed to mean. But coming out of the "if" block,
>freeBytes is always 0 in the release version, but it's set to the correct
>value in the debug version under identical circumstances.
>
>If I change all of the long longs in this example to plain old longs, it
>works. Which would be an OK solution, except that these days, a 32 bit int
>isn't big enough to store the number of free bytes someone might have
>available on their hard disk.
>
>Is this an optimization bug, or am I missing something simple here?
>

-- 
     Free Programming Courses at CodeWarrior U
          <http://www.codewarrioru.com>

 Metrowerks, maker of CodeWarrior  -  "Software Starts Here"  
Ron Liechty - MWRon@metrowerks.com - http://www.metrowerks.com