forums.silverfrost.com

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

The following code with /CHECK_WINIO causes the compiler to crash. I simplified it enough to duplicate the crash that I see with my full code. It is the '%tc%ty&' line that causes the crash.

PaulLaidler · Posted: Fri Jul 05, 2019 5:45 pm Post subject:

Bill

Thank you for the feedback.

Unfortunately there is no alternative to exiting after a winio@ error report at compile time. It is a situation where the compiler can't easily recover and progress. However, I will take another look and check this.

mecej4 · Joined: 31 Oct 2006 Posts: 1899

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

Paul, I can understand why it would be a "one and done". I appreciate you taking another look.

Also as feedback, the specific identification of the variable (or % command) in error is very helpful. Makes up for the multiple compiles it took to find all of the typos in the code!!

Bill

PaulLaidler · Posted: Sat Jul 06, 2019 8:14 am Post subject:

Thanks for the feedback. I will take a look at the documentation.

PaulLaidler · Posted: Sat Jul 06, 2019 9:41 am Post subject:

Bill

The crash with %ty has now been fixed for the next release of the DLLs.

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

Thanks, Paul!!

PaulLaidler · Posted: Tue Jul 09, 2019 9:53 am Post subject:

/CHECK_WINIO checks the type of the arguments against what is expected for the corresponding format codes. It also checks that the number of arguments is correct.

This checking process is, of necessity, less comprehensive than that which is carried out at runtime.

This is a relatively new and experimental feature so false error reports and the occasional crash may occur. Please report these for fixing.

/CHECK_WINIO is unlikely to work with code containing complicated winio@ constructions that use DO loops or IF constructs.

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

Paul,

I'm not sure this qualifies for "fixing", but I did have the occurrence where the argument should have been an external, but was actually a variable. I swapped the two when I typed the argument list. Of course, caught at run-time.

Don't know whether or not that feature could be added.

Just a thought.
Bill

PaulLaidler · Posted: Tue Jul 09, 2019 3:22 pm Post subject:

Bill

Are you saying that /CHECK_WINIO does not fault this?

wahorger · Joined: 13 Oct 2014 Posts: 1257 Location: Morrison, CO, USA

That was my experience. But when I just tried to re-create it in a small example, I could not. I'll try to experiment with more complex examples (i.e. several controls defined in a single winio@() call).

Sorry if this was a red herring.

DanRRight · Posted: Wed Jul 10, 2019 3:49 am Post subject:

I encourage all to try /CHECK_WINIO for faster rate of its bug fixes and improvement of functionality. Right now compiling with /CHECK_WINIO crashes a half of my files but because the large amount subroutines in each compiled file extracting of offensive part would be a hell.

As to functionality i'd still like for /CHECK_WINIO to complain about error with this simplest code compiled FTN95 aaa.f95 /link /check_winio

PaulLaidler · Posted: Wed Jul 10, 2019 8:10 am Post subject:

It is true that ClearWin+ does not check for the use of undefined values and I guess that in some contexts it could. Using /UNDEF may catch most of these errors independently of ClearWin+.

Maybe if someone wants to provide a list of cases that could be tested then this task could be added to the "todo" list.

This reminds me that there is no perfect programming environment and the developer's work is never ending - the goal post are always moving.

One thing that I have in mind is to get ClearWin+ to write Fortran (winio@) code for you for simple dialogs. This is not as far-fetched as it sounds. Visual ClearWin+ already allows you to interactively design a dialog with the data going into a .rcx resource file. The next step would be to automatically convert this into Fortran code.

Having said this, there does not seem to have been much interest in Visual ClearWin+ presumably because there is an associated learning curve and users rarely need to work from scratch in this way. So I am not convinced that it this kind of development would be of interest.

DanRRight · Posted: Wed Jul 10, 2019 8:40 am Post subject:

The problem is that /undef does not catch uninitialized variables with Clearwin. CWP just does eat them for breakfast. And after that sometimes hiccups no one knows where. With this text above: FTN95 aaa.f95 /link /check_winio /undef all looks rosy, but...

As to the acceptance rate - there is no barely used software, there is little advertisement. CWP needs more bright examples.

PaulLaidler · Posted: Wed Jul 10, 2019 9:21 am Post subject:

There is no connection between /UNDEF (which causes FTN95 to plant checking code into your object files) and ClearWin+ which is in an external DLL. But ClearWin+ could possibly check for undefined values at runtime in certain contexts.

p.s. But you would need to use /UNDEF in order to plant the "undef" values in your code then ClearWin+ could look for these values if it had a mind to.