Hi Andrew,

Wednesday June 19 2013 08:50, you wrote to mark lewis:

 AL>    Hello mark!
 AL> 05 Jun 13 13:09, you wrote to Ulrich Schroeter:
 US>>> version a:
 US>>>    int maxnum = 0;
 US>>>    print maxnum results in =>  710691913
 ml>> he aims...
 ml>> C shoots!
 ml>> C Scores!!
 AL> This appears to be an OpenWatcom issue.  I've already modified the
 AL> code to use version b, with no effect on the SearchMaxMSG crash under
 AL> OS/2.

today I've got the debugger running

the program crashes 'cause the _dos_findnext() routine moves a memory segment
into another memory area, which helds the content of the local int variables

the debug report you'll find under
https://sourceforge.net/p/makenl/bugs/17/?limit=10&page=1#2cd6

based on the oswatfnd.c, oswatful.c, oswatxxx.h, osgenaps.c and os.c
an ASM routine _dos_findnext() starts moving around some memory
in the debugger it identifies itself as:
Assembly: findos2
   005B:0002AF6A      findos2@copydir_+0000002A

the code section
 0002AF59                mov      ecx,dword ptr 10[edx]                       
0053:00049474=000000EF
 0002AF5C                lea      edi,1E[eax]
 0002AF5F                mov      dword ptr 1A[eax],ecx                       
0053:000497DE=000000EF
 0002AF62                mov      ecx,00000040
 0002AF67                lea      esi,1D[edx]

>0002AF6A                rep movsd    0053:0004987A=00030

loops until all the defined memory area is moved.

The memory address of maxnum is defined &49878  and aktnum at &4987C
so in every _dos_findnext() the previously maxnum = 0 was reset
to whatever value moved into the ram location by the findnext routine :-P

Solution(s) ?
I don't realy know ...
I assume, that the findfirst() / findnext() code requires a defined
memory allocation ?!?
-or-
further investigation is needed to discover the reason, why _dos_findnext()
writes into a memory area that is allocated by the active process

but the source under oswatfnd.c

char *os_findnext(struct _filefind *pff)
{
    if (_dos_findnext(&pff->fileinfo) == 0)
        return pff->fileinfo.name;

    return NULL;
}

doesn't give much info what's go wrong within _dos_findnext()

As least similar findfirst() findnext() routines
as shown under
http://www.openwatcom.org:4000/@md=d&cd=//&cdf=//depot/public/4o
2/c/wrappers.c &ra=s&c=rGG@//depot/public/4os2/c/wrappers.c?ac=64
has some more code included.

here 2 comments are of interest:
  20 Aug 07 GKY Move #pragma alloc_text to end for OpenWatcom compat
  01 Sep 07 GKY Add xDosSetPathInfo to fix case where FS3 buffer crosses 64k  
boundry

maybe something similar is required for the makenl_ng code  ?!?

 AL> Andrew

regards, uli   ;-)

---
 * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)