forums.silverfrost.com

Wilfried Linder · Posted: Fri Sep 07, 2012 6:36 am Post subject: files@

Just a remark: It seems that the return value number_of_files is not initialised in the routine files@. It would be nice to set this value to zero just at the beginning of the routine:

JohnCampbell · Joined: 16 Feb 2006 Posts: 2593 Location: Sydney

Wilfried,

You should check the documentation for FILES@, as both N and NMAX are INTEGER (KIND=2), which is INTEGER*2, not INTEGER*4.

Only today I again came across the limit of NMAX < 32,768, being limited to 32,767 entries in a directory. I'm not sure if a directory in Windows 7 can have more entries.
My test that N < NMAX failed, so I increased the size of NMAX from 25,000 to 40,000 in my include file, without checking, as a call required more than 25,000.
I now have 32,000 and that is working for my directory scan at the moment.

It would be a nice change if integer*2 could be replaced by integer*4 generally in the library, as is generally in clearwin and observed by Dan.

John

PaulLaidler · Posted: Mon Sep 10, 2012 10:19 am Post subject:

I have had a quick look at the code for FILES@ which indicates that the number of files will be returned as zero when this is the case. Please let me know if using INTGER*2 does not fix the problem.

The use of INTEGER*2 arguments goes back to DBOS days. Although DBOS was a 32 bit extender for the existing Win16, presumably it was necessary to use existing 16 bit graphics routines. DBOS graphics routines were ported to ClearWin which later formed a part of ClearWin+.

As a result there are a number of library routines that pass 16 bit arguments and users do need to be aware of this legacy.

Wilfried Linder · Posted: Mon Sep 10, 2012 11:44 am Post subject:

Indeed, using integer*2 for number_of_files solves the problem. Thank you, John. So it was my mistake...

Regards - Wilfried