READ(*,'(a)') error

[sanjayg0]

I have a simple program

program qwin2
character (len=256) :: record
write(*,*) 'Input: '
read(*,'(a)') record
write(*,*) 'read string', record
end program qwin2

I am using VS 2019 (ver 16.6.2) with Intel Fortran Package ID:w_oneAPI_2021.4.0.364 (installed today), using IFORT and a quick win project, x64.

Compiling and running throws an error of

Expression: (L "Buffer is too small" && 0)

when i enter any string and hit return.  If I just hit return without typing anything the error is

Expression: ((destination)) != NULL && ((size_in_elements)) > 0

Either way the errors are from the read statement.  The stack trace shows problems on Line 22 in QWin2.exe!strncpy_s and Line 218 in QWin.exe!common_tcsncpy_s, so system routines.  Following the stack in the debugger, I can see my input string is correct in the locals for strncpy_s with the correct length as it is in common_tcsncpy_s.

Does anyone know what is going on here?  Thanks in advance for any ideas.

-sanjay

[Steve_Lionel]

I can reproduce this - it's almost certainly a bug in the QuickWin library.  It is new in 2021.4.0 - works in 2021.3.0. Intel support should investigate.

[sanjayg0]

Thanks Steve.  Good to know that I was not chasing a ghost for 6 hours yesterday.  Is there a way that I can roll back to 2021.3.0?  I'll note that had a working much old compiler (parallel studio xe 2017) but see to have lost that while installing the new one

Added information is that this behavior varies by compiler selection IFORT vs IFX as well as target x86 vs x64, and if one switches between using subsystems /subsystem:console vs /subsystem:windows.  I actually tested all 6 allowed permutations and one of these works, 5 fail in one way or another -- maybe that helps is tracking the bug down.

Assuming I did not get overly confused at 3am; here are the results of that effort at creating a quick win program:

• IFORT
  
  • x86
    • subsystem console:  runtime Throws buffer error
    • subsystem windows: runtime Throws buffer error
  • x64
    • subsystem console:  runtime forrtl: The system could not find the environment option that was entered
    • subsystem windows: runtime throws buffer error
• IFX
  •  
  • x64
    • subsystem console:  Works!
    • subsystem windows: build error, unsatisfied external WinMain referenced from int  __cdecl__scrt_common_main_seh

[sanjayg0]

I decided to play around with some of the other IDEs on my box, in particular VS2015 version 14.0.25431.01

Creating the qwin program via VS2015 + IFORT 2021.4.0 (x86 and x64) + /subsystem:windows creates a properly working qwin application.  One thing I note during the build is that the resource compiler version is 6.3.9600.17336.

When I do the same with VS2019 + IFORT 2021.4.0 (x86 and x64) + /subsystem:windows,  I see that it is using Resource Compiler Version 10.0.10011.16384 and the executable throws the buffer error.

[In About for VS2015, it lists parallel studio xe 2017, but the build log window shows it is using IFORT (Classic) 2021.4.0]

[Steve_Lionel]

Unless you uninstalled it, 2021.3.0 is still installed on your system. In Visual Studio, go to Tools > Options > Intel Compilers and Libraries > IFORT Intel Fortran Classic > Compilers. Change "Selected Compiler" as desired. Keep in mind that this is platform-specific, so if you are building 64-bit you'll need to select the x64 tab.

From the command line, there are shortcuts in the Start menu for each installed version.

[sanjayg0]

I've marked this as the "solution" since reverting to 2021.3.0 solves my issue; notwithstanding the bug in 2012.4.0 is still there.  Hopefully Intel support has made note of this issue and will fix it in the next release.

[Neels]

I really hope so as I had to do the same to "fix" the error!

[Neels]

The error is still there in 2021.5.0

[sanjayg0]

That's too bad; I would have guessed that this would be a simple fix.  Have your tried 2022.0.0, which seems to be out now?

[Neels]

Yes, when you download it it says 2022.1.0.93 but after installing it it says 2021.5.0. I downloaded it today to test.

[sanjayg0]

Bummer.  Can anyone from Intel give an indication of when this bug will get fixed?

[Devorah_H_Intel]

This issue was escalated to compiler engineering for a fix.  I can't say how soon it will be fixed. 

[sanjayg0]

Hi Devorah.  Thanks for the note.  I really really look forward to seeing this bug fixed -- as do the 1000s of users of our software.

[preshenne]

Hi Devorah -

See Also the string:

https://community.intel.com/t5/Intel-Fortran-Compiler/Run-Time-Breakpoint-for-Simple-Code/m-p/1351149/

Same problem with 2021.4

I just updated from a 2015 version with new VS and OneAPI for Intel Fortran Classic 2021.4.  Based on all these experiences the latest Intel Fortran Classic 2021.4 and Subs are unuseable and should be recalled.  It literally calls into question what was the testing protocol for this compiler?  Fails a simple READ statement - really????

Preston Henne

[Neels]

Thank you Devorah,

If they need an example or anything else like a screen shot of the errant line in the Qwin library etc. let me know please.

[Steve_Lionel]

I suspect part of the problem is that QuickWin applications can't readily be tested in an automated environment. This error is specific to QuickWin and does not affect non-QuickWin applications.

QuickWin itself is ancient - it was inherited from Microsoft PowerStation - and hasn't had much attention over the years. It is great for simpler things, and I admit to being astonished that changes were made that broke it.

[sanjayg0]

Hi Steve. 

Yep QuickWin is old! Our code has been under active development since the 1970s and QuickWin is one of those things that has stuck.  I would love to ditch it but since I am mostly a Unix type, I have not figured out how to make the switch. 

Our basic program has only two windows.  There is a text input/output terminal window and then there is a graphics window onto which we draw polygons, lines, and place text strings, and read mouse clicks -- so pretty basic.  On Linux and Macs, we use a standard terminal for the input/output window and an X11 window for the graphics.  Synchronous I/O multiplexing, i.e. FD_SET etc., is used to concurrently poll input from the two windows. 

There must certainly be a way to do this in Windows outside of QuickWin.  If you have some pointers for where to start to learn how to do this outside of QuickWin, that would be super.  I imagine switching from QuickWin should not be too too difficult -- maybe one day's worth of work, max.

[Steve_Lionel]

The big advantage QuickWin has is its integration with Fortran I/O, which no other solution has. But it sounds as if you don't really need that as you have an implementation on other platforms.

There are a couple of Fortran-friendly third-party libraries that you may find useful: Gino and Winteracter. There's also the free, but 32-bit only and not maintained in years Xeffort.

Another option is OpenGL, though this has fallen out of favor in recent years. There's a pretty full interface provided by Intel Fortran as well as some examples in the sample bundle. An advantage of using OpenGL is that it is very portable.

[preshenne]

If the error is in QUICKWIN, then why does code from earlier compilers function correctly and code from later compliers not function correctly?  Seems to me the compiler update precipitates this problem.  The problem may present in QUICKWIN but it is precipitated by something in 2021.4 & Subs that was done and and is incompatible with QUICKWIN.  I have many QUICKWIN / FORTRAN Programs and to change now is a big deal.

[Steve_Lionel]

It's not a compiler problem, it's a QuickWin library problem.

[preshenne]

If its a QUICKWIN library problem, then it should be fixed pronto as all those programs out there are using a defective library and causing untold problems.  When is Intel's fix scheduled for?