One correction to my advice on the about setting the data breakpoint. You want to set it using "&this->bufferAddress", not "this->bufferAddress". The this shouldn't really be necessary. That's probably why it didn't work for you before.
Rick On Thu, Jun 19, 2008 at 12:34 PM, Mark Miesfeld <[EMAIL PROTECTED]> wrote: > > On Thu, Jun 19, 2008 at 8:07 AM, Rick McGuire <[EMAIL PROTECTED]> wrote: >> >> See my comments below. >> >> On Thu, Jun 19, 2008 at 10:08 AM, Mark Miesfeld <[EMAIL PROTECTED]> >> wrote: >> > ... I just took out the position--; line >> > >> >> All of those look reasonable. Thanks for digging in to this! Go >> ahead and check these in. > > Okay, I will. <grin> > >> >> > read() returns true at eof, and looks like it is intended to return true >> > for >> > that condition. So, I changed getChar() to only return true if it >> > actually >> > got a new char: >> >> Well, the problem is in read. Those functions are supposed to return >> true if they read data, and false if they didn't return data for any >> reason. > > I'll see about fixing that in read then. > >> >> I had similar problems with linein() trying to get Rexxtry to >> work. I did a quick search for other places where I'd made the >> mistake, but obviously I missed at least one. >> >> > However, since gets() may have collapsed a /r/n into a single byte, I >> > added >> > in an extra arg that would report if /r/n was collapsed into /n. >> >> Hmmm....probably the appropriate thing would be to ask the SysFile >> object what the current read position is rather than trying to infer >> it from the length that was returned. > > Yes, I redid that this morning to use SysFile.getPosition() and cleaned it > up. > >> >> > So it looks like the bufferAddress member of StreamInfo has gotten >> > overwritten. I still get baffled trying to figure those out, so that's >> > where I quit. >> >> These are actually pretty easy to figure out in Visual Studio. Set a >> break point at the place where the buffer pointer is allocated, then >> set a data breakpoing on "this->bufferAddress". This will catch the >> overlay for you when it happens. > > I'll try that, again. You've pointed out this technique to me before. > <grin> I think the problem I had this time was that I was trying to set > the data breakpoint directly on bufferAddress and couldn't get the debugger > to resolve it. I didn't think to use 'this'. > >> >> This is terrific progress! Thanks for taking the time to look at >> these. Don't be too hesitant about checking in fixes for these >> problems in the future. If you have, a fix, and it fixes the problem, >> go ahead and commit it. If you're not certain about the fix, ask for >> a review of the commit. If there's another course that should be >> taken, I can correct it there. > > I'm slowly getting less shy. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
