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.
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.
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:
- subsystem console: runtime Throws buffer error
- subsystem windows: runtime Throws buffer error
- subsystem console: runtime forrtl: The system could not find the environment option that was entered
- subsystem windows: runtime throws buffer error
- subsystem console: Works!
- subsystem windows: build error, unsatisfied external WinMain referenced from int __cdecl__scrt_common_main_seh
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]
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.
Hi Devorah -
See Also the string:
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????
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.
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.
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.
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.
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.
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.