I am indeed using /size32 (because I am using the size function a few times and I was getting many warnings because I am saving the output of the size as an INTEGER*4). So I will remove the /size32 for now. Thanks

How big is "major"? A lot of work has already been done including moving large static arrays to virtual storage. Certainly by the time of the next release one can be confident of "significant" enhancements.

Paul, Often big projects issue so called night builds. Firefox browser for example doing that for all betatesters who are interested. Reason for that is that numerous testers may find hidden bugs much faster and report them.

Can at least few enthusiasts or at the final least those who are on current support contracts get latest builds and upgrades on their request? The 2-3 recent DLLs (DLLs from 6) already substantially conflict with the older stable release ver.810 (Clearwin+ and debugger now crashing completely unreasonably and often just after the loading of the program without touching anything) so I can not use them. If compiler developers do not experience crashes that may tell that very substantial changes were made recently which conflicts with older releases. I noticed that some people do not have crashing problems with latest DLLs, which may tell that their codes are small, they do not use debugger, numerous tricky libraries etc. If compiler developers also work with small codes (which is very reasonable to imply) they may also miss the compiler problems users with large problems may immediately experience.

The issue raised here by StamK has now been reviewed. The outcome for the next release of FTN95 is that the effect of /SIZE32 (which currently is an alias for /SIZE_ISO) has been modified.

This will mean that the above code will compile as expected when using /SIZE_ISO but /SIZE32 will remain as a special device that allows certain 32 bit code be ported to 64 bits without change.

So /SIZE32 will continue to cause the above failure and its use should be avoided in almost all circumstances.

For those who really want to know: /SIZE32 can be used as a quick fix when porting from 32 bit to 64 bits and when a call to SIZE is made whilst passing an argument to a user defined generic routine as for example in CALL generic_fun(SIZE(x)).

Statistically speaking it should appear within the next week .... or in May._________________''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "

Further work has now been completed on this issue with the result that the FTN95 command line option /SIZE32 should now be redundant. If you added this option when porting from 32 bit to 64 bits in order to get your code working then you should be able to work without it (from the next release). If not then please let me know.

The option /SIZE_ISO is retained and meaningful. Now, for 64 bits, by default the SIZE intrinsic (without a KIND specifier) continues to return a 64 bit integer except when it appears as an argument. By using /SIZE_ISO, FTN95 becomes standard conforming which means that by default SIZE always returns an integer (or integer array) of type "default integer".