Hello Ulrich!

Tuesday June 04 2013 03:15, Ulrich Schroeter wrote to Andrew Leary:

 US> first, I've found the compile problem that is caused by
 US> the filepointer around BatchFILE in main routine (makenl.c  line ~325)
 US> see latest report under bug#17

I'll check that out this afternoon.

 US> What I could debug down is that the routine SearchMaxMSG() crashes
 US> in the return sequence to the calling routine OpenMSGFile()

This is where I've noticed the OS/2 crashes also.

 US> Whatever workaround I've tried to fix the return sequence
 US> it crashes under OS/2 32-bit  :(

Yes, I know.

 US> the problem may relate to the local int variable, that will be used
 US> to return the result to the calling routine, where the result
 US> will be assigned to a static int variable.

That is a definite possibility.  I'll have to research that further.

 US> Don't know if there is a problem in the byte length of the used
 US> integer variable under SearchMaxMSG() ?!? Another problem that I've
 US> found, while declaring and defining a 0 value to an integer variable
 US> in the SearchMaxMSG() routine was:

 US> version a:
 US>    int maxnum = 0;
 US>    print maxnum results in =>  710691913

That's definitely not right!

 US> version b:
 US>    int maxnum;
 US>    maxnum = 0;
 US>    print maxnum results in =>  0            (as expected)

As it should be.

 US> so whatever memory block has been read under version a, it tells me
 US> that something unusual is going on here with the integer type
 US> of the used variables
 US> At least this indicates the crash by an integer return of
 US> the SearchMaxMSG() function  (is a 64 bit integer required here ?!?)

It shouldn't be, but I'll look into that.  Maybe this is the result of the
work that was done to get the code to compile on 64-bit Linux systems.

 US> Someone with much more C/C++ experiences then me should dig into this
 US> code section

I'm learning more all the time.

Andrew

---
 * Origin: Bits & Bytes BBS * V.Everything! * 860/535-4284 (1:320/119)