You statements led me to debug from the good ol' green screen and I am in
agreement with y'all because when I do an EVAL GDATAPTR1:X 1024 I then see
the last character being the x'70'.
So I went back to my "trusted" WDSC and did the following steps (which are
the same ones that led me to the screen shots):
1) Right click on gDataPtr and select Monitor Memory->Hex.
2) Right click on the first address that is now highlighted by default and
select Go To Address...
3) Now a non-modal dialog is at the bottom of the Memory view and in the
drop down I select Go to Offset
4) In the text box I enter 1024, de-select the Input as Hex, and select
the OK button.
The above steps position me to 1025 like you are suggesting and NOT 1024
(Aaron shakes his fist at the sky). What the heck!? Is there some weird
offset rules with Memory view? Note this is WDSC v7.0.x
So that led me to look at the process that I am passing my gDataPtr1 to
and it is in THERE that my code is slapping me around. In that code I am
basically taking the contents of the pointer and converting it to base64
encoded but what I am NOT doing is stopping at the right point.
AAAARGGGGHHH! Completely my oversight, but everyone's comments helped me
verify that. For a second I thought the IFS read() api was acting funky
on me and that would be a very bad thing as I read/write to IFS files A
LOT (I had a little sweat rolling down my back :-)
Thanks everybody for responding,
Aaron Bartell
[1]
http://mowyourlawn.com
p.s. If you want to see me shave parts of my body please head over to
[2]
http://firstgiving.com/aaronbartell to learn how to make it happen.
Yes it sounds gross, but it is for a good cause!
References
Visible links
1.
http://mowyourlawn.com/
2.
http://firstgiving.com/aaronbartell
midrange.com
